Month: August 2008

Picking up where we left off last time…

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.

What can be very frustrating is that we do reach out to all the major distros, and a number of the less major ones.  But we don’t talk to every single person on every single distro; we can’t.  We also try to follow best practices for an open project: open version control, open IRC, open mailing lists.

Part of the problem may be that we also talk to independent software developers, and sometimes, distro people aren’t prepared to hear what developers are saying.  So, it looks like we’re pushing things on them, like predictable directory layouts, hooks for working with the user environment, different options for software installation, and the like.

We used to just listen to distros and do what they wanted.  Part of the reason there’s still a lingering perception that “the LSB failed” is that software developers saw us as irrelevant.  And they were right: we were irrelevant, because we only listened to the distros.  So now we listen to both sides, and try to get them to talk to each other, and act as a go-between when they don’t seem able to.

I had an eye-opening experience in Berlin in 2006.  We talked to packaging people, and talked about the need for cooperation between package managers and third-party installer tools. A lot of people thought that was a bad idea.  So we got them together with some major ISVs in Berlin, and told them to figure it out.  And they did figure something out, and surprise!  Communication between package managers and third-party installers became a good thing, at least if done right.

And we don’t have a problem with the “done right” part, either.  We made a few attempts at proposals for the communication system above, and someone has created an independent implementation.  Some of those proposals came under sharp criticism.  And we’re cool with that; happy, in fact, that it got attention.

So if you want to find out what’s going on with us, and what terrible things we’re going to make you do in the future, check out our project plan, sign up for our mailing list, or just come by our IRC channel (irc.linuxfoundation.org, #lsb) and ask some questions.  We try to be friendly and helpful.

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…