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 > >
