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
signature.asc
Description: This is a digitally signed message part.