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 <[email protected]> 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 <[email protected]> >> 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 >> >>
