Debian dropping the Linux Standard Base

The Linux Standard Base (LSB) is a specification that purports to define the services and application-level ABIs that a Linux distribution will provide for use by third-party programs. But some in the Debian project are questioning the value of maintaining LSB compliance—it has become, they say, a considerable amount of work for little measurable benefit.

The LSB was first released in 2001, and was modeled to a degree on the POSIX and Single UNIX Specification standards. Today, the LSB is maintained by a working group at the Linux Foundation. The most recent release was LSB 5.0 in June 2015. It defines five LSB modules (Core, Desktop, Languages, Imaging, and Trial Use).

The bulk of each module consists of a list of required libraries and the mandatory version for each, plus a description of the public functions and data definitions for each library. Other contents of the modules include naming and organizational specifications, such as the filesystem layout in the Filesystem Hierarchy Standard (FHS) or directory specifications like the Freedesktop XDG Base Directory specification.

In what appears to be sheer coincidence, during the same week that LSB 5.0 was released, a discussion arose within the Debian project as to whether or not maintaining LSB compliance was a worthwhile pursuit for Debian. After LSB compliance was mentioned in passing in another thread, Didier Raboud took the opportunity to propose scaling back Debian's compliance efforts to the bare minimum. As it stands today, he said, Debian's lsb-* meta-packages attempt to require the correct versions of the libraries mentioned in the standard, but no one is actually checking that all of the symbols and data definitions are met as a result.

Furthermore, the LSB continues to grow; the 4.1 release (the most recent when Debian "jessie" was released) consisted of "1493 components, 1672 libs, 38491 commands, 30176 classes and 716202 interfaces," he said. No one seems interested in checking those details in the Debian packages, he noted, adding that "I've held an LSB BoF last year at DebConf, and discussed src:lsb with various people back then, and what I took back was 'roughly no one cares'." Just as importantly, though, the lack of interest does not seem to be limited to Debian:

Raboud proposed that Debian drop everything except for the lsb-base package (which currently includes a small set of shell functions for use by the init system) and the lsb-release package (which provides a simple tool that users can use to query the identity of the distribution and what level of LSB compliance it advertises).

In a follow-up message, he noted that changing the LSB to be, essentially, "whatever Debian as well as all other actors in the FLOSS world are _actually _doing" might make the standard—and the effort to support it in Debian—more valuable. But here again, he questioned whether anyone was interested in pursuing that objective.

If his initial comments about lack of interest in LSB were not evidence enough, a full three months then went by with no one offering any support for maintaining the LSB-compliance packages and two terse votes in favor of dropping them. Consequently, on September 17, Raboud announced that he had gutted the src:lsb package (leaving just lsb-base and lsb-release as described) and uploaded it to the "unstable" archive. That minimalist set of tools will allow an interested user to start up the next Debian release and query whether or not it is LSB-compliant—and the answer will be "no."

Raboud added that Debian does still plan to maintain FHS compliance, even though it is dropping LSB compliance:

After the announcement, Nikolaus Rath replied that some proprietary applications expect ld-lsb.so* symbolic links to be present in /lib and /lib64, and that those symbolic links had been provided by the lsb-* package set. Raboud suggested that the links should be provided by the libc6 package instead; package maintainer Aurelien Jarno said he would accept such a patch if it was provided.

The only remaining wrinkle, it seems, is that there are some printer-driver packages that expect some measure of LSB compliance. Raboud had noted in his first message that OpenPrinting drivers were the only example of LSB-compliant packages he had seen actually distributed. Michael Biebl noted that there was one such driver package in the main archive; Raboud replied that he believed the package in question ought to be moved to the non-free repository anyway, since it contained a binary driver.

With that, the issue appears to be settled, at least for the current Debian development cycle. What will be more interesting, naturally, will be to see what effect, if any, the decision has on broader LSB acceptance. As Raboud alluded to, the number of distributions that are certified as LSB-compliant is small. It is hard not to notice that those distributions are largely of the "enterprise" variety.

Perhaps, then, LSB compliance is still important to some business sectors, but it is hard to know how many customers of those enterprise distributions genuinely care about the LSB certification stamp. If Debian's experience is anything to go by, however, general interest in such certification may be in steep decline.