Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Is C++ code still part of 1.5 release?

Copy link to this message
Re: Is C++ code still part of 1.5 release?
The expectation that downloading it, untar'ing it, and running it
without compiling *does* (or should... that's what we're supposed to
be reviewing) work with the -bin that was produced. What you're
expecting to also work is one particular add-on feature that requires
compilation from source to work, as an optimization.

The -bin that has been produced is arch-dependent, and provided for
x86_64, el6-compatible convenience. There is *nothing* to stop anybody
from rolling another similar -bin package that is for a different
architecture or target OS.

Now, perhaps we should seriously consider simply omitting the native
maps add-on from the binary package entirely, so that our binary
packaging is noarch, and providing separate arch-dependent binary
distributions of those that need it (this is actually something I had
hoped to accomplish for 1.6).

Christopher L Tubbs II
On Fri, May 17, 2013 at 5:19 PM, Michael Allen <[EMAIL PROTECTED]> wrote:
> Just a quick weigh in here:
> As a user of open source software, I have no expectation that a file called
> "-bin" have zero source code in it.  What I expect is that I should be able
> to download a thing called "-bin", untar it and run it without having to do
> a compile.  To make it run *fast*, I would expect to do "something else"
> where that might be compiling something or configuring something.  I would
> *not* expect that a *common* way to make something run fast be included in
> something *else* that I have to download.  That just makes me think that
> the people that put this "-bin" together for me wanted me to jump through
> extra hoops to make it run right.
> To William's point about seeing a Makefile and thinking I have to build
> something to make it work: I don't think the Makefile is at the top level
> directory, right?  Given that, I might never see it unless I go poking
> around for it (or find instructions that direct me to it).
> - Mike
> On Fri, May 17, 2013 at 5:12 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>> I'm with Michael on this one. We should really only be releasing one
>> package that has all of the source and built binaries. IMO the
>> interpretation of http://www.apache.org/dev/release.html that we must have
>> a source-only release is overly restrictive. "Every ASF release must
>> contain a source package, which must be sufficient for a user to build and
>> test the release provided they have access to the appropriate platform and
>> tools." can also be interpreted such that a single package with source and
>> binaries meets the release requirement.
>> I have seen a lot of confusion about people trying to build the accumulo
>> code when they really don't need to, and they often run into trouble when
>> their environment is not set up for java development. Having multiple
>> .tar.gz artifacts adds to this confusion. When we reordered the download
>> page so that the -dist.tar.gz came before the -src.tar.gz those types of
>> questions dropped dramatically on the mailing list. The existence of the
>> -src.tar.gz creates confusion on its own (although our README doesn't
>> help).
>> Adam
>> On Fri, May 17, 2013 at 4:00 PM, Michael Berman <[EMAIL PROTECTED]> wrote:
>> > As an Accumulo user, the thing I want most is a single package that
>> > contains the things I need to set up a running instance.  I don't want to
>> > build the whole thing from source, but I am happy to build the native
>> map,
>> > unless every possible architecture is going to be distributed.  I really
>> > don't care at all whether the tarball name ends in "-bin" or "-package"
>> or
>> > "-theStuffYouWant".  If the only reason not to include the native map
>> > sources in the binary release is because the filename ends in -bin, why
>> not
>> > just call it accumulo-1.5.0.tar.gz?
>> >
>> >
>> > On Fri, May 17, 2013 at 3:51 PM, John Vines <[EMAIL PROTECTED]> wrote:
>> >
>> > > If we're going to be making binary releases that have no other