Debian 拋弃 Linux 标准规范（LSB）
LSB Debian
<ruby> Linux 标准规范 <rp>  （ </rp> <rt>  LSB，Linux Standard Base </rt> <rp>  ） </rp></ruby>是一个意图定义 Linux 发行版为第三方程序所提供的服务和应用层<ruby> 程序二进制接口 <rp>  （ </rp> <rt>  ABI，Application Binary Interfaces </rt> <rp>  ） </rp></ruby> 的[规范](http://refspecs.linuxfoundation.org/lsb.shtml)。但 Debian 项目内的某些人正在质疑是否值得维持兼容 LSB，他们认为，该项工作的工作量巨大，但好处有限。


![](/data/attachment/album/201510/12/103118rdprw2lwcf2f7hxp.jpg)


LSB 于2001年首次公布，其模型建立在 [POSIX](https://en.wikipedia.org/wiki/POSIX) 和<ruby> <a href="https://en.wikipedia.org/wiki/Single_UNIX_Specification">  单一 UNIX 规范 </a> <rp>  （ </rp> <rt>  Single UNIX Specification </rt> <rp>  ） </rp></ruby>的基础之上。目前，LSB 由 Linux 基金会的一个[工作小组](http://www.linuxfoundation.org/collaborate/workgroups/lsb)维护。最新的版本是于2015年6月发布的 [LSB 5.0](http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50)。它定义了五个 LSB 模块（<ruby> 核芯 <rp>  （ </rp> <rt>  core </rt> <rp>  ） </rp></ruby>、桌面、语言、<ruby> 成像 <rp>  （ </rp> <rt>  imaging </rt> <rp>  ） </rp></ruby>和试用）。


每个模块都包含了一系列所需的库及其强制性版本，外加对每个库的公共函数和数据定义的描述。这些模块还包括命名和组织规范，如<ruby> <a href="http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs">  文件系统层次标准 </a> <rp>  （ </rp> <rt>  FHS，Filesystem Hierarchy Standard </rt> <rp>  ） </rp></ruby>中的文件系统布局或象 Freedesktop 的<ruby> <a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html">  XDG 基础目录 </a> <rp>  （ </rp> <rt>  XDG Base Directory </rt> <rp>  ） </rp></ruby>规范这样的目录规范。


似乎只是一个巧合，就在 LSB 5.0 发布的同一周，Debian 项目内部针对其是否值得保持兼容 LSB 进行了一次讨论。在另一个贴子中，在提及兼容 LSB 后，Didier Raboud 顺势[提议](https://lwn.net/Articles/658838/)将 Debian 的兼容工作维持在最低水平。他说，目前的情况是，Debian 的“lsb-\*” <ruby> 元包 <rp>  （ </rp> <rt>  meta-packages </rt> <rp>  ） </rp></ruby>试图规定该标准中提及的库的正确版本，但事实上却没有人去检查所有的符号和数据定义是否满足要求。


另外，LSB 还不断在膨胀；他说， LSB 4.1 版（接近 Debian “jessie” 发布时的最新版本）包含“**1493个组件、1672个库、38491条命令、30176个类和716202个接口**”。似乎没有人有兴趣检查 Debian 包中的这些细节，他解释道，又补充说，“**去年在 DebConf 上我举行过一次 LSB BoF，后来又与很多人讨论过 src:lsb，我收回自己的‘几乎没有人在意’的说法**”。但，重要的是，Debian 似乎并不仅局限于兴趣的缺乏：



```
我认为，这个问题的关键在于是否值得去玩这整个游戏：我还没听说有哪个软件通过 LSB 包来发行。LSB 认证的应用清单上只有 6个公司的_8_个应用，其中仅有一个是针对不低于 LSB 4 的。

```

Raboud 提议 Debian 摈弃除了 [lsb-base](https://packages.debian.org/sid/lsb-base) 包（目前包括一个用于启动系统所需的小的 shell 函数集合）和 [lsb-release](https://packages.debian.org/sid/lsb-release) 包（提供一个简单工具，用户可用它查询发行版的身份以及该发行版宣称的与哪个 LSB 级别兼容）之外的所有内容。


[后来](https://lwn.net/Articles/658842/)，他又称，将 LSB 基本上改变为“**Debian 和 FLOSS 世界中的所有的其它人所实际做的任何事**”可能会使得该标准（以及在 Debian 为支持它所做的工作）更有价值。但此时他再次质疑是否有人会对推动这个目标有兴趣。


如果说他最初称 LSB 中缺乏兴趣没有足够的证据，随后整整三个月之内没有任何人对维持 LSB 兼容的包提供支持，并进行了两次拋弃它们的投票。最后，9月17日，Raboud [宣布](https://lwn.net/Articles/658843/)他已经抽掉 `src:lsb` 包（如前所述，保留了`lsb-base` 和 `lsb-release`），将将其上载到 “unstable” 归档中。这个最小的工具集可以让感兴趣的用户在启动了下一个 Debian 版本后查询它是否兼容 LSB：结果将为“否”。


Raboud 补充说，即便摈弃了兼容 LSB，Debian 仍计划继续兼容 FHS：



```
但 Debian 并没有放弃所有的 LSB：我们仍将严格遵守 FHS（直到 Debian Policy 版本 2.3；虽然今年8月已经发布了3.0），而且我们的 SysV 启动脚本几乎全部遵循 VIII.22.{2-8}。但请不要误解，此次 src:lsb 上载明确说明我们将离开 LSB。

```

在该宣告之后，Nikolaus Rath [回应](https://lwn.net/Articles/658846/)称某些私有应用依赖`/lib`和`/lib64`中的符号链接`ld-lsb.so*`，而这些符号链接由`lsb-*`包提供。Raboud 则[建议](https://lwn.net/Articles/658847/)应改由`libc6`包提供；该包维护人员Aurelien Jarno [称](https://lwn.net/Articles/658848/)，如果提供这样一个补丁，他将会接受它。


似乎唯一的遗留问题只是某些打印机驱动包会依赖 LSB 兼容。Raboud 称，在其首个贴子中已经说明，据他所知，实际发布的唯一一个依赖 LSB 兼容的包为 [OpenPrinting](http://www.linuxfoundation.org/collaborate/workgroups/openprinting/) 驱动程序。Michael Biebl [称](https://lwn.net/Articles/658844/)，主归档中有这样一个驱动包；Raboud 则[回应](https://lwn.net/Articles/658845/)说，他认为这个有问题的包应该被移到非自由仓库，因其包括了一个二进制驱动。


于是，这个问题看上去已经尘埃落定，至少对于目前的 Debian 开发周期来说是如此的状况。很自然的是，未来让人更感兴趣的是，如果该决定存在一些影响的话，那么人们将会看到它对更广泛的 LSB 接受度有何影响。正如 Raboud 所说的那样，被认证为 LSB 兼容的发行版数量很[少](https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb)。人们很难不会注意到这些发行版很大程度上是“企业”的变种。


也许，对某些商业领域来说，LSB 仍很重要，但很难知道有多少那些企业发行版的客户真正关心 LSB 认证标签。然而，如果 Debian 的经验靠得住的话，对这种认证的一般兴趣可能会急剧下降。




---


via：<https://lwn.net/Articles/658809/>


作者：Nathan Willis 译者：[Yuking](https://github.com/Yuking-net) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译， [Linux中国](https://linux.cn/) 荣誉推出


OK
# Debian dropping the Linux Standard Base

LWN.net needs you!Without subscribers, LWN would simply not exist. Please consider

[signing up for a subscription]and helping to keep LWN publishing.

The Linux Standard Base (LSB) is a [specification](http://refspecs.linuxfoundation.org/lsb.shtml)
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](https://en.wikipedia.org/wiki/POSIX) and [Single
UNIX Specification](https://en.wikipedia.org/wiki/Single_UNIX_Specification) standards. Today, the LSB is maintained by a
[working
group](http://www.linuxfoundation.org/collaborate/workgroups/lsb) at the Linux Foundation.
The most recent release was [LSB 5.0](http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50) 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](http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs) (FHS) or
directory specifications like the Freedesktop [XDG
Base Directory](http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html) 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](/Articles/658838/) 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 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:
[ lsb-base](https://packages.debian.org/sid/lsb-base)
package (which currently includes a small set of shell functions for
use by the init system) and the

[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).](https://packages.debian.org/sid/lsb-release)

`lsb-release`In a follow-up [message](/Articles/658842/),
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](/Articles/658843/) 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](/Articles/658846/) 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](/Articles/658847/) that the links should be
provided by the `libc6` package instead; package maintainer Aurelien
Jarno [said](/Articles/658848/) 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](http://www.linuxfoundation.org/collaborate/workgroups/openprinting/) drivers were
the only example of LSB-compliant packages he had seen actually distributed.
Michael Biebl [noted](/Articles/658844/) that there was one
such driver package in the main archive; Raboud [replied](/Articles/658845/) 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](https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb).
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.

Posted Oct 1, 2015 8:12 UTC (Thu)
by
Posted Oct 1, 2015 8:45 UTC (Thu)
by
Posted Oct 1, 2015 10:14 UTC (Thu)
by
Posted Oct 2, 2015 9:34 UTC (Fri)
by
Posted Oct 8, 2015 14:58 UTC (Thu)
by
Posted Oct 9, 2015 3:29 UTC (Fri)
by
Short list of Oracle's Sun acquisitions and what's happened since:
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.
Posted Oct 9, 2015 15:43 UTC (Fri)
by
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.
Posted Oct 1, 2015 8:52 UTC (Thu)
by
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.
Posted Oct 1, 2015 9:01 UTC (Thu)
by
Posted Oct 1, 2015 9:17 UTC (Thu)
by
Posted Oct 1, 2015 9:22 UTC (Thu)
by
The lsb-release package containing the lsb_release command is going to stay, as mentioned in the article.
Posted Oct 1, 2015 9:25 UTC (Thu)
by
« 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
Posted Oct 1, 2015 9:48 UTC (Thu)
by
Posted Oct 8, 2015 14:59 UTC (Thu)
by
Posted Oct 8, 2015 18:59 UTC (Thu)
by
Posted Oct 9, 2015 13:17 UTC (Fri)
by
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
Posted Oct 9, 2015 16:19 UTC (Fri)
by
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.
Posted Oct 11, 2015 10:28 UTC (Sun)
by
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,
Posted Oct 10, 2015 15:30 UTC (Sat)
by
Instead, I proposed using the Technical Support Alliance (
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.
Posted Oct 28, 2015 9:54 UTC (Wed)
by
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.
[
][
]## Debian dropping the Linux Standard Base

**mjthayer** (guest, #39183)
[[Link](/Articles/658884/)] (6 responses)

[
]## Debian dropping the Linux Standard Base

**pabs** (subscriber, #43278)
[[Link](/Articles/658890/)] (5 responses)

[
]## Debian dropping the Linux Standard Base

**mjthayer** (guest, #39183)
[[Link](/Articles/658900/)] (4 responses)

[
]## Debian dropping the Linux Standard Base

**ewan** (subscriber, #5533)
[[Link](/Articles/658998/)]

[
]## Debian dropping the Linux Standard Base

**pabs** (subscriber, #43278)
[[Link](/Articles/659957/)] (2 responses)

[
]## Debian dropping the Linux Standard Base

**linuxrocks123** (subscriber, #34648)
[[Link](/Articles/660068/)] (1 responses)


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




[
]## Debian dropping the Linux Standard Base

**orclev** (guest, #104847)
[[Link](/Articles/660139/)]


[
]## How to find out the system's codename without lsb_release?

**rschroev** (subscriber, #4164)
[[Link](/Articles/658887/)] (7 responses)


[
]## How to find out the system's codename without lsb_release?

**cortana** (subscriber, #24596)
[[Link](/Articles/658891/)] (1 responses)

[
]## How to find out the system's codename without lsb_release?

**rschroev** (subscriber, #4164)
[[Link](/Articles/658897/)]

[
]## How to find out the system's codename without lsb_release?

**zwenna** (guest, #64777)
[[Link](/Articles/658898/)]


[
]## How to find out the system's codename without lsb_release?

**noirbee** (subscriber, #61940)
[[Link](/Articles/658896/)] (1 responses)



[
]## How to find out the system's codename without lsb_release?

**rschroev** (subscriber, #4164)
[[Link](/Articles/658899/)]

[
]## How to find out the system's codename without lsb_release?

**pabs** (subscriber, #43278)
[[Link](/Articles/659958/)] (1 responses)

[
]## How to find out the system's codename without lsb_release?

**rschroev** (subscriber, #4164)
[[Link](/Articles/660008/)]

[
]## Debian dropping the Linux Standard Base

**criswell** (guest, #40091)
[[Link](/Articles/660102/)] (2 responses)






because it was something easily predictable as far back as 2008.

[
]## Debian dropping the Linux Standard Base

**dlang** (guest, #313)
[[Link](/Articles/660146/)]


[
]## Debian dropping the Linux Standard Base

**Wol** (subscriber, #4433)
[[Link](/Articles/660312/)]




Wol

[
]## Debian dropping the Linux Standard Base

**jbailey** (subscriber, #16890)
[[Link](/Articles/660253/)]

[https://www.tsanet.org/](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.


[
]## Debian dropping the Linux Standard Base

**dbp** (guest, #105070)
[[Link](/Articles/662239/)]