Standards and Conversations, Part 1

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

Creative Commons License
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

5 thoughts on “Standards and Conversations, Part 1

  1. Hi and thanks for raising this issue.

    I’m Niklas Andersson, writing for Swedish netmag TechWorld Open Source.

    I’ve worked with Red Hat between versions 4.2 and 8.0 during the time when resolving package dependencies was a head ache at best.

    With Debian 3.1 I ran into very few problems and with Ubuntu I haven’t had any issues this far (besides some I’m responsible of myself due to my own bad packaging).

    My question is: Has LSB mechanisms for resolving package dependencies in a distribution neutral manner?

    Without such mechanism I find it difficult to create a one-size-fits-all-standard.

    Me personally think that a common namespace (how packages are named) is more important than RPM vs APT.

  2. James:

    The simple answer is to point to the LSB’s deprecation policy; we can’t just drop things. But that’s not really an answer.

    Most ISVs are even less happy with the idea that they must outsource their installation to the distros than they are with RPM.

    The last time we got ISVs and distro people in the same room to talk about this problem, they came up with the Berlin Packaging API. But that’s turned out to be controversial as well, especially among those who weren’t at that meeting.

    We’ve talked about deprecating RPM support in the past. But some ISVs want to interact with the package manager; before we have something like the Berlin API, I don’t know that we’ll be helping them by simply removing capabilities.

  3. Niklas:

    We really don’t say much about package dependencies in the LSB. LSB packages have strict limitations on the kinds of dependencies they can have; the basic idea is that they depend either on “”lsb” or on other packages provided by the vendor.

    I don’t think unifying package namespaces is going to work, mostly because it implies a level of cooperation and deference that isn’t really possible. People have their own ideas for how these things should be done.

    Of course, if someone else can manage to pull it off, we wouldn’t mind being proved wrong.

Comments are closed.