Hi Gunnar,
just jumping on one specific point, sorry to hijack the thread…
(Reply-To set to debian-lsb, please followup there…)
tl;dr: proposal to shrink src:lsb to only produce lsb-base and lsb-
release
Le jeudi, 2 juillet 2015, 09.15:12 Gunnar Wolf a écrit :
> But then I realized I was lying.
>
> Debian does take care to implement several standards (i.e. following a
> LSB-compliant POSIX system
This is only true to a certain extent: we do [0] care about a certain
level of compatibility with LSB around initscripts and the existence of
a lsb_release binary [1]. Debian has (ab)used the src:lsb package to
host more and more common code over the years (see your /lib/lsb/init-
functions{,.d/} and all of lsb-base): "left info blocks", all the
log_{daemon,progress,end,action_msg shell functions, etc. (Sadly enough,
there's even a code difference between the Ubuntu and Debian versions of
pidofproc. /o\ )
But… the largest part of the LSB specification is about API
compatibility: all the
lsb-{base,core,cxx,desktop,graphics,languages,multimedia,printing,security}
packages _try_ to make sure that the correct packages are present, but
there is (as far as I know) nobody on the Debian side actually
_checking_ that all symbols are actually present, or that they stay
present. At the time of LSB4.1, for x86, we were talking about 1493
components, 1672 libs, 38491 commands, 30176 classes and 716202
interfaces [2].
(There's of course also the FHS, that we modify with our own exceptions
anyway, but it is part of the LSB.)
We're also not checking this because the LSB compatibility of Debian
releases has never been a topic and I don't see anyone asking a library
maintainer to stay at an older version and/or maintain a patch series to
keep this compatibility [2]. By the way, the only organism that I know
is regularly checking Debian's LSB compatibility, is the Linux
Foundation [3]. They haven't tried Jessie yet apparently.
(There _exists_ a Distribution Checker, but last I looked, it was an
intense headache to setup.)
The crux of the issue is, I think, whether this whole game is worth the
work: I am yet to hear about software distribution happening through LSB
packages [4]. There are only _8_ applications by 6 companies on the LSB
certified applications list [5], of which only one is against LSB >= 4.
Amongst the distributions, RHEL 7.0 is LSB4.1, and Oracle 6, RHEL 6.0
and Ubuntu 9.04 are LSB 4.
As a data point, I've just noticed that the Linux Foundation issued
LSB 5.0 and FHS 3.0 [6] just yesterday. But that doesn't change the
arguments, I think.
I've held an LSB BoF last year at DebConf [7], and discussed src:lsb
with various people back then, and what I took back was "roughly noone
cares". Since then, the package just floated in the limbo down my TODO
list.
Now, given all this, I'm considering the following (and seeking advice
and/or support):
* accepting that LSB certification is not a goal for us, and give up
explicitely,
* therefore truncating the src:lsb package to the only things that are
still obligatory: lsb-base & lsb-release.
Opinions? Thanks in advance, and sorry for the quite long mail!
Cheers,
OdyX
[0] Mostly _did_, when SysVinit was the de-facto standard…
[1] Which is currently broken for sid users, as I just noticed now when
writing this email.
[2] The package descriptions contain:
> The intent of this package is to provide a best current practice way
> of installing and running LSB packages on Debian GNU/Linux. Its
> presence does not imply that Debian fully complies
> with the Linux Standard Base, and should not be construed as a
> statement that Debian is LSB-compliant.
[3] http://www.linuxbase.org/navigator/browse/distr.php?cmd=list-byid&Did=476
[4] There are some OpenPrinting driver packages, but that shouldn't
matter for all FLOSS drivers.
[5] https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb
[6] http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50
[7] DebConf14 BoF: https://summit.debconf.org/debconf14/meeting/104/lsb-for-debian-bof/ and debconf14/bof/LSB on gobby.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.