LifeKeeper[1] was initially produced by AT&T in 1992 and ran on a proprietary System V like UNIX OS. The product was bought by SteelEye Technology in 1999 with the object of porting it to Linux (this makes us extremely motivated application vendors).
We began in January 2000 with the aim of making LifeKeeper run on RedHat 6.0. During the initial project, which was scheduled to take about 3 months, RedHat 6.1 was released. ``No big deal, we thought, we'll just use 6.1 as the base instead.'' The first product was finally released, on RedHat 6.1 in June 2000. Shortly thereafter, the Marketing Department agreed to go on a road-show tour with Caldera. ``Of course it will work, it's just Linux'', they said. ``Er...Hang on, let us test it first!'', we replied. Sure enough, the pristinely rpm[5] packaged software wouldn't even install on Caldera (some of the packages we list as requirements have different names on Caldera). When we forced it to install, it wouldn't start on machine boot up like it was supposed to (the init system is different). Finally, when we started it manually, it dumped core and died. The reason? we have a fixed shared memory area at 0x7fff0002, but the eServer kernel was compiled with the 2GB option meaning the shared libraries were actually occupying this area--``It's just Linux--Sure!''.
We solved these issues by producing a special ``for demonstration purposes only'' package for the Caldera road-show. This seemed to be leading us unwittingly in the direction of one package per distribution. However, with the advent of RedHat 7.0 even the embryonic single package per distribution strategy was starting to fail: Some of the applications changed names or plain just wouldn't run with the new version of glibc.
This traditional UNIX flavour approach (produce one package for each distinct distribution3) wasn't flying well with our Sales Department either: ``I just want to sell them one CD, I don't want to give them the third degree about what flavour of Linux they're running--I didn't even know Linux had flavours''. And from the engineering perspective, the alternative of a single package containing all distributions looks like a release and a Quality Assurance (QA) nightmare (how do we add a new distribution quickly to our monolith? do we have to test on all distributions when we make a change specific to one?).
Even worse: at the moment the distributions we support all use the RedHat Package Manager (rpm). However, there are distributions (like Debian) that don't use this. How would we get our packages to install on these systems?