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
