Debian dropping the Linux Standard Base
Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
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 " 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, " 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.
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:
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.
(Log in to post comments)
Debian dropping the Linux Standard Base
Posted Oct 1, 2015 8:12 UTC (Thu) by mjthayer (guest, #39183) [Link]
Debian dropping the Linux Standard Base
Posted Oct 1, 2015 8:45 UTC (Thu) by pabs (subscriber, #43278) [Link]
Debian dropping the Linux Standard Base
Posted Oct 1, 2015 10:14 UTC (Thu) by mjthayer (guest, #39183) [Link]
Debian dropping the Linux Standard Base
Posted Oct 2, 2015 9:34 UTC (Fri) by ewan (subscriber, #5533) [Link]
Debian dropping the Linux Standard Base
Posted Oct 8, 2015 14:58 UTC (Thu) by pabs (subscriber, #43278) [Link]
Debian dropping the Linux Standard Base
Posted Oct 9, 2015 3:29 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link]
Short list of Oracle's Sun acquisitions and what's happened since:
1. Java: Main distribution still under Oracle's control
2. Solaris: un-open-sourced by Oracle; IllumOS fork "won" by virtue of being only remaining option
3. MySQL: developer revolt; MariaDB fork won
4. OpenOffice: developer revolt; LibreOffice fork won
5. Hudson: developer revolt; Jenkins fork won
6. VirtualBox: Oracle still in control
So, of those six OSS projects, Oracle has managed to alienate the communities of three and unsuccessfully attempted to outright kill one. Good job, Oracle.
Oracle OSS is dying. Java and VirtualBox are all that remains. Red ink flows like a river of blood ;)
But, Java and VirtualBox are probably still around because Oracle pays most of the developers. So, if we want those projects to be better governed, someone will need to step forward to hire those guys away or hire new guys to replace them. Java is likely recognized as "too big to fail" by Oracle, so their funding is why they're in control, and VirtualBox is probably just basically on ice and no one has cared enough to fork it yet. Both of those situations could change in time -- but, without some catalyst, probably won't change any time soon.
Debian dropping the Linux Standard Base
Posted Oct 9, 2015 15:43 UTC (Fri) by orclev (guest, #104847) [Link]
The fact that the standards process still involves Oracle in any significant fashion I think is largely a red herring, if OpenJDK decided to deviate from Oracle I suspect most developers would go with it and abandon Oracle JDK. The only really troubling part there is the recent court case between Google and Oracle over the copyright-abiltity of the Java API, which might prove troublesome for OpenJDK should they decide to part ways with Oracle entirely.
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 8:52 UTC (Thu) by rschroev (subscriber, #4164) [Link]
It's easy enough to find the release number, but I'm always having trouble finding the mapping between release numbers and codenames. I haven't found an overview on Debian's website; I need to resort to Wikipedia or the source of the lsb-release package.
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 9:01 UTC (Thu) by cortana (subscriber, #24596) [Link]
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 9:17 UTC (Thu) by rschroev (subscriber, #4164) [Link]
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 9:22 UTC (Thu) by zwenna (guest, #64777) [Link]
The lsb-release package containing the lsb_release command is going to stay, as mentioned in the article.
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 9:25 UTC (Thu) by noirbee (subscriber, #61940) [Link]
« Raboud proposed that Debian drop everything except for the lsb-base […] and the lsb-release package »
In addition to /etc/os-release, /etc/debian_version also contains some codename information, but I'd advise against using anythin
How to find out the system's codename without lsb_release?
Posted Oct 1, 2015 9:48 UTC (Thu) by rschroev (subscriber, #4164) [Link]
How to find out the system's codename without lsb_release?
Posted Oct 8, 2015 14:59 UTC (Thu) by pabs (subscriber, #43278) [Link]
How to find out the system's codename without lsb_release?
Posted Oct 8, 2015 18:59 UTC (Thu) by rschroev (subscriber, #4164) [Link]
Debian dropping the Linux Standard Base
Posted Oct 9, 2015 13:17 UTC (Fri) by criswell (guest, #40091) [Link]
The problems the Debian developers point out are nothing new. The LSB has had these problems for years.
The crux of the problem is that the LSB is a trailing standard and that it has (or had, I honestly can't say for certain if this is still the case) a heavy corporate interest. This creates a situation where the LSB is always REACTING to the changing Linux distro universe, which means it can never, really, be relevant as it is always just a bit out of date. In turn, this creates problems for distros wanting to be LSB compliant as they, essentially, have to have these backwards shims in place to keep the LSB checkers happy.
The LSB's modus operandi is to debate and reach consensus on each and every change. On paper, this sounds good. However, in practice it's absolutely miserable. It means that discussions drag on forever and things are added, updated, or removed long after they've ceased to be relevant in mainstream distros. Additionally, you have corporations (or had, again, it could be different) which would lobby for particular technologies and often get them included in the LSB not based upon technical merit but instead upon how much noise the company was able to generate with the LSB and the Linux Foundation. Personally, I butted against this problem back in my day at the LSB as a major change I thought was absolutely stupid (allowing non-root users to modify package management DBs like the RPM DB- a feature MANY companies trying to make packages for Linux wanted at the time) kept being brought up again and again largely because the companies in question were also Linux Foundation contributors. (This change never made it in, of course, as doing so would have made every distro in the world reject it, but it didn't change the fact that the stupid suggestion kept getting proposed and shot down on a nearly monthly basis and that there was pressure from management in the LF to keep these companies happy since they were giving so much money.)
The only solution to these problems is to ditch the "LSB by committee" approach and, instead, have the LSB be semi auto-magickally generated based upon what REAL distros are doing. We had this tool at the time (which was made by researchers at a major computer science academy) which could analyze the ABI interfaces available in a given distro (the tool was intended to be used as a way to easily determine LSB compliance). That tool could have easily been used to determine ABI commonality among major distros, which could have then been used to defined the LSB in a very relevant and real way. Re-running this tool every 6 months or so, and generating the LSB based upon what the distros were actually doing, would have kept the LSB current. This was something I advocated for at the time, but was ultimately rejected (again, largely because of the corporate interests involved that had very specific agendas for the LSB).
Anyway, while it makes me sad to see the LSB fall further into obscurity (it really was a good idea and had noble goals) this doesn't exactly surprise me
because it was something easily predictable as far back as 2008.
Debian dropping the Linux Standard Base
Posted Oct 9, 2015 16:19 UTC (Fri) by dlang (guest, #313) [Link]
such a tool (and a report like you are describing) would do wonders to deal with the "linux is fragmented, every distro requires it's own build" meme. It would either confirm that this is the case (and point at what distros or upstream projects are the cause of breakage), or provide very solid information to combat the meme.
Debian dropping the Linux Standard Base
Posted Oct 11, 2015 10:28 UTC (Sun) by Wol (subscriber, #4433) [Link]
As a keen WordPerfect user, I wanted some way of specifying "these are the requirements to run commercial program X", and the LSB just seemed to me to be completely missing the point.
If we want to install commercial programs on linux, it would make life so much easier if the LSB just defined a bunch of pseudo-packages the distribution installers all understood, that would make sure the pre-requisites are installed on the system so the commercial installer "just runs". And it looked reasonably easy to me back then - except I just got the feel that the LSB was intent on going in a different direction :-(
Cheers,
Wol
Debian dropping the Linux Standard Base
Posted Oct 10, 2015 15:30 UTC (Sat) by jbailey (subscriber, #16890) [Link]
Instead, I proposed using the Technical Support Alliance (https://www.tsanet.org/) to build a partnership for ISVs to work with distros. The idea being that if someone has a support contract with OEM, OS vendor and ISV, the support ticket can be placed to whomever, and the vendors have means to talk to one another and actually resolve problems on behalf of the customer. This provides appropriate incentives to everyone in support of their mutual customer and encourages recurring revenue through support contracts to involved vendors.
I saw this as the best way for Ubuntu to be taken seriously on servers. Most of the ISVs we wanted were already part of TSANet, so I felt pretty confident in our ability to bring them on over a few years, starting with smaller ones. Unfortunately, between Murdock doing his Champagne Supernova and me leaving Canonical, the idea never went any further.
Debian dropping the Linux Standard Base
Posted Oct 28, 2015 9:54 UTC (Wed) by dbp (guest, #105070) [Link]
Most of the products require specific distro and major version, some relax to more distros and versions. The point is once the vendor claim which platform is supported, they need to support until EOL.
Claiming to support "LSB" is just too uncertain and risky to the vendor, as stated by jbailey.