incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Bayer <>
Subject Re: Packaging concerns
Date Mon, 22 Aug 2011 15:43:27 GMT
We definitely need to have bigtop in either the package name or the package
version - on Thursday, we talked about putting it in the package version.
With that, the package version would probably be something like
"0.23.0+bigtop_0.2.0-1" or something along those lines - I'm not familiar
enough with package version formatting to be sure. =)


On Sat, Aug 20, 2011 at 6:22 PM, Eric Yang <> wrote:

> Hi Eli,
> I was appraising bigtop goal for making a stack of releasable Hadoop
> software.  It's hard work that not many people would be interested to take
> on, and end user taking install package for granted.  However, I am
> concerned that having the down stream project to make usable package would
> result in accumulate code in the down stream project rather than moving code
> to the mainline.  This may not be a problem at the moment, but it would be
> good to set in a clear direction to avoid potential pitfalls.
> What would bigtop released package be labelled?
> bigtop-hadoop-namenode-0.23.0-1.x86_64.rpm?  What does the version number
> mean?  Is the version number Hadoop controlled number or bigtop controlled
> number?  If the version number is Hadoop version number, how do bigtop
> version it's own version number?  Some clarity is appreciated.
> regards,
> Eric
> On Aug 20, 2011, at 11:47 AM, Eli Collins wrote:
> > Hi Eric,
> >
> > Not sure what you're referring to. Bigtop does not patch the Apache
> > release tarballs. There's nothing novel about packaging an open source
> > project, most open source projects don't build their own packages.
> >
> > Thanks,
> > Eli
> >
> > On Sat, Aug 20, 2011 at 11:10 AM, Eric Yang <>
> wrote:
> >> Greetings big top developers,
> >>
> >> Bigtop has started it's own packaging customization build process using
> Linux distributions based packaging tools to fully customize Hadoop stack
> packages.  In traditional GPL camp, meta package to build source and apply
> patches as part of rpm/deb package construction.  The advantage is that you
> can apply hot fix to the open source related source to customize to fit
> Linux distributions.
> >>
> >> In Apache, software are released as tar ball with md5 signature.
>  Ideally, Apache released rpm/deb packages should be the same bits that is
> in the release tar ball.  There is no need to apply patch build mechanism
> because the software release should be identical regardless if it is
> packaged by rpm/deb/tar.  This is the reason that I chosen to wrap
> rpm/debian packages on top of release binary tarball to ensure the
> tarball/rpm/debian packages are identical.  This is also done in each Hadoop
> projects instead of having a umbrella project to customize the software
> stack to ensure software are released at pace of the source project.
> >>
> >> Back in 2004, Covalent was releasing HTTPD server in RPM form, they had
> done the traditional RPM + patch release, which stirred some community
> issues that tar ball release and RPM binaries are not in-sync.  Apache HTTPD
> project stopped distributing RPM form after a couple short releases.  From
> the history lesson, I choose not to repeat past mistakes.
> >>
> >> It seems bigtop has chosen to use traditional Redhat/Debian methodology
> of producing bits to fit Linux distributions.  It is a novel goal from a
> packaging purity perspective.  However, you might want to pay close
> attention to license and potential pitfalls.  It may be more interesting to
> focus on testing the community produced packages in MHO.
> >>
> >> regards,
> >> Eric

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message