accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Is C++ code still part of 1.5 release?
Date Fri, 17 May 2013 21:36:34 GMT
I think the point here is that *a* copy of the compiled native maps *is* 
included. The point here is that the compiled library is now 
platform/architecture dependent, and, how far should we go to make 
things easier?

Adam, I don't recall seeing "dramatically less emails" on our lists, so 
I would have to disagree with you on that point. Christopher does bring 
up a good point on this subject: "what does -dist even mean?". Should it 
work on linux-amd64? Linux-x86? OSX-intel? Windows-x64? OSX-ppc? Sparc?

In the interest of actually making something positive come out of this 
that satisfies all parties, I move that we make an 
${artifact}-${version}-src.tar.gz and 
${artifact}-${version}-something.tar.gz. '-src' contains the expected 
ASF source release, and '-something' contains the source and compiled 
artifacts (platform specific and not). If '-something' == '-dist', 
that's fine. In fact, I really don't care in that regard. If someone has 
a better suggestion than '-dist' which is succinct and more descriptive, 
I'd be happy to use that suggestion instead.

If I missed some caveat here, I apologize.

On 5/17/13 5:19 PM, Michael Allen 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 <> 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 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 <> 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 <> wrote:
>>>> 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" <> 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 <>
>>> 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
>>>>>>> -bin.tar.gz to make their life easier.
>>>>>>> This is a very simple decision. It really doesn't matter how
>> 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 <
>>>>>>>**> 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
>> and
>>>>>>>> installing them separately. Personally, for development and
>>> testing, I
>>>>>>>> don't use them.
>>>>>>>> Since we're building RPMs and debian packages, the steps
>> install
>>> an
>>>>>>> add
>>>>>>>> on is roughly 20 keystrokes.
>>>>>>>> On Fri, May 17, 2013 at 2:22 PM, Josh Elser <
>>>>>>> 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
>>> easiest
>>>>>>>> and
>>>>>>>> I
>>>>>>>>> believe makes the most sense. My opinion is that source
>>> 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
>> 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:

View raw message