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