So it looks like the project I’ve been laboring on has been getting some attention:

Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier.

They even link to our project status page.  Cool!

Of course, good publicity invites criticism.  This time, there seem to be two themes.  William Pitcock seems to have the most succinct summary:

To put things simply, the LSB sucks. Here’s why:

• The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?
• The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.

(See also Scott James Remnant.)

Let’s take this one part at a time.  Today’s topic: packaging.

Part of William’s problem may be that he doesn’t understand the spec.  The LSB doesn’t require a specific package manager, or a specific package format.  It doesn’t even require that the distribution be set up using package management at all!

The spec only requires that LSB-compliant software be distributed so that any LSB-compliant distribution can install it.  That could be tarballs with POSIX-compliant install scripts, an LSB-compliant install binary, a shar archive, a Python script with embedded base64 binaries, whatever.  One of the options allowed is an RPM package, with a number of restrictions.

The restrictions are key, because they effectively define a subset of RPM that acts as, to quote William again:

…a simple package format that can be converted on demand into the system package format…

The difference being, of course, that we didn’t reinvent the wheel and create our own; we used a popular format as the basis for ours.

Scott raises another concern:

While much of the LSB can be hacked into a different distribution through compatibility layers and tools, such as alien, what ISV or other vendor wants to provide a support contract against a distribution that has such kludges?

I’m not sure if he’s referring specifically to packaging or to the standard in general.  As regards packaging: the reason we specify a strict subset is because we can test that subset, and we’ve tailored it to the needs of tools such as alien.  The theory goes that alien isn’t a kludge when it comes to LSB packages.

But, as already mentioned, if vendors aren’t comfortable with supporting RPM, they have a number of other options.  As it turns out, most of them are doing just that; the feedback we’re getting from most ISVs is that packaging (whether LSB-subset RPM, full RPM, or Debian) is just not worth the effort.

Coming up: part 2…