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 <[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
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" <[email protected]> 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 <[email protected]>
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 <
[email protected]**> 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 <[email protected]
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:
