I agree with you, Christopher. I don't think it's unreasonable to expect
a user to download something else if the packaged .so doesn't work on a
user's system. Write that down, etc, etc.
But, that does beg the question: what version of glibc are we going to
build against? That could influence my opinion on the subject..
On 05/13/2013 05:18 PM, Christopher wrote:
I question whether the following four steps should be considered a
"tremendous headache", simply because of the fact that one needs to
download a different file than the one already downloaded...
1. Download source tarball
2. Unpack source tarball
3. Navigate to server/src/main/c++
4. Run "make"
... but I can easily add it back in if that's the consensus.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 13, 2013 at 11:34 AM, John Vines <[email protected]> wrote:
That sounds like a tremendous headache for the users where the pre-built
native libraries aren't sufficient.
On Mon, May 13, 2013 at 11:13 AM, Christopher <[email protected]> wrote:
Yeah, you could essentially unpack the source over the binary... for
now, anyway... but some things would be slightly different. Like the
addition of the proxy/thrift directory for the generated thrift
bindings pulled out of proxy/target/. But... I really don't think it
should be a goal to make the source directory structure and the binary
directory structure overlap like this. The binary tarball should
really just a "ready to use" thing, and the source should be a "ready
to develop or re-package" thing.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi
<[email protected]> wrote:
On Sun, May 12, 2013 at 8:45 PM, Christopher <[email protected]>
wrote:
I went through all the rpms and debs and tarballs to check to see if
they were including the right things (ACCUMULO-1404).
Personally, I don't think they should be in a binary-release... source
code that needs to be compiled sounds like something you'd get out of
the source tarball, so I assumed its inclusion was an oversight that I
was correcting. (I did make sure the *.so files were included.) If
there's a reason to keep source code in a binary package, then, I can
add it back in, but really, if you can't use it out of the box, I'm
not sure it should be in the binary tarball.
This would be a change from what we were doing with "dist" releases, but
I
am not necessarily against it. I find it nice to have the source there,
as
I often look things up in it. To reproduce the previous structure,
would I
be able to just unpack the source release over the binary release?
Billie
This is related to another issue I was looking at also, so i'll mention
it
here:
What do we include for proxy thrift bindings? I see that currently
we're dropping in the gen-rb, gen-java, and gen-py folders from the
proxy thrift compilation. However, I'm not so sure we should be doing
this... because:
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.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Sun, May 12, 2013 at 11:22 PM, David Medinets
<[email protected]> wrote:
I ran this command:
git clone --branch 1.5 https://github.com/apache/accumulo.git
then compiled to get a binary-release.tar.gz file. That gz file does
not
seem to contain the C++ files to build the native libraries. Should
they
be
there? I don't recall hearing about removing them.
