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 Mon, 22 Aug 2011 16:21:40 GMT
RPM package name meta data structure looks like this:

[PackageName]-[Version]-[ReleaseRevision].[Vendor].[Arch].rpm

Hence, bigtop might be able to use:

hadoop-common-0.23.0-0.2.1.bigtop.x86_64.rpm

Where release-revision number is bigtop version number, and overload vendor tag with bigtop
branding.

For debian package, this is not clear.

[PackageName]_[VersionNumber]-[DebianRevisionNumber]_[DebianArchitecture].deb

hadoop-common-bigtop_0.23.0:0.2.1-1_x86_64.deb

This is some what usable and it probably won't confuse the users with projects produced packages.

regards,
Eric

On Aug 22, 2011, at 8:43 AM, Andrew Bayer wrote:

> 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. =)
> 
> A.
> 
> On Sat, Aug 20, 2011 at 6:22 PM, Eric Yang <eyang@hortonworks.com> 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 <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