If we're going to be making binary releases that have no other mechanism for creating the native libraries, then we should probably cut a few different binary releases for x86, amd64, and darwin at the very least.
Sent from my phone, please pardon the typos and brevity. On May 17, 2013 12:36 PM, "Josh Elser" <josh.el...@gmail.com> wrote: > I'm happy we're stating our opinions here, but there are also two other > people who believe that the bin should not contain it. That's nice that you > want source code in a binary release, but your opinion is not the only one. > I feel like you're telling me that my opinion is sub-par to your opinion > because it is. > > If this is such a sticking point, I move that we completely kill the > notion of source and binary releases and make one tarball that contains > both. > > On 5/17/13 3:17 PM, John Vines wrote: > >> I agree with Adam. It seems like it's a debate of consistency vs. >> pragmatism. The cost of including these libraries are all of maybe 1kb in >> the package. The cost of excluding them is potential frustration from end >> users and a lot of repetitive stress against the Apache Mirrors (lets try >> and be considerate). I think it's a no brainer, but I have yet to here a >> reason that is not 'no source code in a binary release!' >> >> >> On Fri, May 17, 2013 at 12:11 PM, Adam Fuchs <afu...@apache.org> wrote: >> >> Just to solidify the decision that Chris is already leaning towards, let >>> me >>> try to clarify my position: >>> 1. The only reason not to add the native library source code in the >>> -bin.tar.gz distribution is that src != bin. There is no measurable >>> negative effect of putting the cpp files and Makefile into the >>> -bin.tar.gz. >>> 2. At least one person wants the native library source code in the >>> -bin.tar.gz to make their life easier. >>> >>> This is a very simple decision. It really doesn't matter how easy it is >>> to >>> include prebuilt native code in some other way or build the code and copy >>> it in using some other method. Those are all tangential arguments. >>> >>> Adam >>> >>> >>> >>> >>> On Fri, May 17, 2013 at 2:49 PM, William Slacum < >>> wilhelm.von.cl...@accumulo.net**> wrote: >>> >>> I think of the native maps as an add on and they should probably be >>>> >>> treated >>> >>>> as such. I think we should consider building a different package and >>>> installing them separately. Personally, for development and testing, I >>>> don't use them. >>>> >>>> Since we're building RPMs and debian packages, the steps to install an >>>> >>> add >>> >>>> on is roughly 20 keystrokes. >>>> >>>> >>>> On Fri, May 17, 2013 at 2:22 PM, Josh Elser <josh.el...@gmail.com> >>>> >>> wrote: >>> >>>> >>>> I believe I already voiced my opinion on this, but let me restate it >>>>> >>>> since >>>> >>>>> the conversation is happening again. >>>>> >>>>> Bundling the native library built with a "common" library is easiest >>>>> >>>> and >>> >>>> I >>>> >>>>> believe makes the most sense. My opinion is that source files should be >>>>> included in a source release and that a bin release doesn't include >>>>> >>>> source >>>> >>>>> files. Since we're specifically making this distinction by making these >>>>> releases, it doesn't make sense to me why we would decide "oh, well in >>>>> >>>> this >>>> >>>>> one case, the bin dist will actually have _some_ src files too." >>>>> >>>>> Is it not intuitive that if people need to rebuild something, that they >>>>> download a src dist (and bin) to start? :shrug: >>>>> >>>>> >>>>>
