incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <>
Subject Re: Packaging concerns
Date Sat, 20 Aug 2011 18:47:10 GMT
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.


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

View raw message