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. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>
