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?
Michael Berman 2013-05-17, 20:00
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