incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Yang <ey...@hortonworks.com>
Subject Re: Packaging concerns
Date Sun, 21 Aug 2011 01:22:47 GMT
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 <eyang@hortonworks.com> 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


Mime
View raw message