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
