I am actually in favour of putting any bigtop string in packages names. Whether the packaging comes from projects directly of bigtop, there may be some packages already available on some GNU/Linux distributions. We should avoid any confusion or hack to get versions working together. There is also too much confusion about the patching policy, despite being abundantly documented and repeated. So I am affraid adding something like "+bigtop_<bigtop_version>" would only keep the confusion around.
Note: Bigtop version is not needed since it should rather be set at the repository level. On 08/22/2011 08: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 >>
