Adam, I agree. As long as a user / system admin has a quick (and well-documented) path to getting the native map where it needs to go in the binary distribution, I think both 1 & 2 are viable. I tend to lean towards #1, for no reason other than that it adds 1 step but is much more maintainable.
On Fri, May 17, 2013 at 3: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: > > > > > > > > > On 5/17/13 2:04 PM, Adam Fuchs wrote: > > > > > >> Chris, > > >> > > >> I like the idea of including the most widely used library, but > empirical > > >> evidence tells me that roughly half of the users of Accumulo will > still > > >> need to compile/recompile to get native map support. There is no > reason > > >> not > > >> to make that as easy as possible by including the cpp code in the > > >> -bin.tar.gz -- at least I haven't heard a reason not to do that yet. > > >> > > >> Adam > > >> > > >> > > >> > > >> On Fri, May 17, 2013 at 11:53 AM, Christopher <ctubb...@apache.org> > > >> wrote: > > >> > > >> Adam, I didn't make any changes on this, because there were only a > few > > >>> opinions, and it didn't seem like there was a consensus. I can make > > >>> this change, though, if a consensus is established. It's very small, > > >>> and easy to do. > > >>> > > >>> Billie, any of those options would work. I'm not sure we need to > > >>> recommend a particular one over the other, as long as users know how > > >>> to get there. > > >>> > > >>> An option that Keith and I were discussing is possibly packaging > > >>> against glibc-2.5 by default, which should reduce the impact on > people > > >>> using RHEL/CentOS 5, but should still work for RHEL/CentOS 6 or > > >>> anything newer (though they may have to install compat-glibc-2.5). > I'm > > >>> not sure the appropriate modifications to make to get this to work, > > >>> though. > > >>> > > >>> -- > > >>> Christopher L Tubbs II > > >>> http://gravatar.com/ctubbsii > > >>> > > >>> > > >>> On Fri, May 17, 2013 at 10:49 AM, Billie Rinaldi > > >>> <billie.rina...@gmail.com> wrote: > > >>> > > >>>> On Fri, May 17, 2013 at 7:26 AM, Adam Fuchs <afu...@apache.org> > > wrote: > > >>>> > > >>>> Folks, > > >>>>> > > >>>>> Sorry to be late to the party, but did we come to a consensus on > > this? > > >>>>> Seems like we still have opinions both ways as to whether the cpp > > code > > >>>>> should be packaged with the binary distribution. I would argue that > > cpp > > >>>>> code is a special case, since the build is so platform dependent. > > It's > > >>>>> generally hard to distribute the right .so files to cover all > > >>>>> platforms, > > >>>>> and we have run into many cases in practice where the native maps > > don't > > >>>>> work out of the box. While downloading the source and untarring it > > over > > >>>>> > > >>>> the > > >>> > > >>>> same directory is not too much extra work, > > >>>>> > > >>>> > > >>>> > > >>>> I'm neutral on whether the source files should be included in the > > binary > > >>>> artifacts. However, I wanted to point out that it sounds like > > untarring > > >>>> the source over binaries is not the recommended procedure. So what > is > > >>>> > > >>> the > > >>> > > >>>> recommended procedure? Untar the source, navigate to the c++ > > directory, > > >>>> build, and drop the resulting .so file into an existing binary > > >>>> installation? Or just build your own binary tarball from source? > > >>>> > > >>>> Billie > > >>>> > > >>>> > > >>>> it seems like the only argument > > >>>> > > >>>>> not to package the native source code with the binary distribution > > is a > > >>>>> dogmatic one. Are there any practical reasons why it would be bad > to > > >>>>> add > > >>>>> the cpp file to the bin distribution? > > >>>>> > > >>>>> > > >>>> Adam > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, May 13, 2013 at 10:48 PM, Eric Newton < > eric.new...@gmail.com > > > > > >>>>> wrote: > > >>>>> > > >>>>> Rumor has it that one of the core developers is irrationally > hostile > > >>>>>> > > >>>>> to > > >>> > > >>>> perl. > > >>>>>> > > >>>>>> And octal. > > >>>>>> > > >>>>>> And xml. > > >>>>>> > > >>>>>> He's just old and cranky. > > >>>>>> > > >>>>>> -Eric > > >>>>>> > > >>>>>> > > >>>>>> On Mon, May 13, 2013 at 5:29 PM, David Medinets < > > >>>>>> > > >>>>> david.medin...@gmail.com > > >>>>> > > >>>>>> wrote: > > >>>>>>> > > >>>>>> > > >>>>>> How come perl is getting no love? > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mon, May 13, 2013 at 10:40 AM, Josh Elser < > josh.el...@gmail.com > > > > > >>>>>>> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> On 5/12/13 11:45 PM, Christopher wrote: > > >>>>>>>> > > >>>>>>>> 1) we don't need to include java bindings for the proxy; > compiled > > >>>>>>>>> versions are already in the proxy jar, > > >>>>>>>>> 2) not all packagers will even have installed thrift with the > > >>>>>>>>> > > >>>>>>>> ability > > >>>>> > > >>>>>> to produce ruby and python bindings, > > >>>>>>>>> 3) these may or may not be helpful to any particular end user > > >>>>>>>>> > > >>>>>>>> (though > > >>>>> > > >>>>>> it's probably safe to assume ruby and python will be the most > > >>>>>>>>> > > >>>>>>>> common), > > >>>>> > > >>>>>> 4) we're not including the proxy.thrift file, which is perhaps > > >>>>>>>>> > > >>>>>>>> the > > >>> > > >>>> most important file for the proxy, and including it should be > > >>>>>>>>> sufficient. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 1)That works. I should've caught that when I was in the proxy > > >>>>>>>>> > > >>>>>>>> last > > >>> > > >>>> and > > >>>>>> > > >>>>>>> I > > >>>>>>> > > >>>>>>>> didn't.Thanks for that. > > >>>>>>>> 2) Do you mean packagers as in people who might make an official > > >>>>>>>> > > >>>>>>> release? > > >>>>>> > > >>>>>>> I would think these are the only people that "really" matter, and > > >>>>>>>> > > >>>>>>> thus > > >>>>> > > >>>>>> I > > >>>>>> > > >>>>>>> would expect them to be able to build a full distributionthat > > >>>>>>>> > > >>>>>>> include > > >>> > > >>>> these > > >>>>>>> > > >>>>>>>> bindings. It might be nice to be able to create a packaging for > > >>>>>>>> > > >>>>>>> each > > >>> > > >>>> language (gem, egg, etc); but until we have some sort of > > >>>>>>>> > > >>>>>>> packaging, > > >>> > > >>>> I'd > > >>>>> > > >>>>>> really like to see theruby and pythonsources included even in the > > >>>>>>>> > > >>>>>>> binary > > >>>>>> > > >>>>>>> dist. > > >>>>>>>> 3)True, but I'd rather set the bar as low as possible for people > > >>>>>>>> > > >>>>>>> who > > >>> > > >>>> just > > >>>>>> > > >>>>>>> want to play around in a scripting language with Accumulo. > > >>>>>>>> 4) Definitely want to make sure it's included. > > >>>>>>>> > > >>>>>>>> Does anyone have an opinion on other languages that thrift > > >>>>>>>> > > >>>>>>> supports > > >>> > > >>>> that > > >>>>>> > > >>>>>>> we should also create bindings for? I concur with your opinion on > > >>>>>>>> > > >>>>>>> Ruby > > >>>>> > > >>>>>> and > > >>>>>>> > > >>>>>>>> Python, but I wonder if there's something else that people would > > >>>>>>>> > > >>>>>>> also > > >>> > > >>>> like. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>> > > >> > > >
