Re: Status of the src:lsb package (was: Debian LSB compliance)
On Sep 17, Didier 'OdyX' Raboud wrote: > This change landed in stretch on September 14. and is de facto the > "outright giving up" of LSB support for Debian, from stretch onwards. As Is there any point in (formally?) maintaining LSB compatibility? Is there any proprietary application that does actually benefit from it in the real world? -- ciao, Marco pgpNYlEV5_i0Z.pgp Description: PGP signature
Status of the src:lsb package (was: Debian LSB compliance)
Hi all,
It is time for an update about the lsb source package status, especially
as a quite important change landed in testing.
After the discussion [0] about these changes back in July (on both
debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to
unstable, building no LSB compatibility packages anymore (besides lsb-
release and lsb-base). As far as I could see, this didn't affect
anything in unstable at the time (and that's how things should be).
This change landed in stretch on September 14. and is de facto the
"outright giving up" of LSB support for Debian, from stretch onwards. As
mentionned in the NEWS.Debian entry, the lsb-base (init-functions) and
lsb-release packages are still available, and are here to stay: lsb-
release has 102 reverse-depends, and lsb-base has 800+ reverse-depends.
But Debian's not throwing all of the LSB overboard: we're still firmly
standing behind the FHS (version 2.3 through Debian Policy; although 3.0
was released in August this year) and our SysV init scripts mostly
conform to LSB VIII.22.{2-8}. But don't get me wrong, this src:lsb
upload is an explicit move away from the LSB.
I will keep an eye on src:lsb, but really, I don't intend to invest much
more time; so I'll happily hand over maintainership to anyone wanting to
invest time in LSB 5.0 Debian support.
Cheers,
OdyX
[0] https://lists.debian.org/4682310.7LIWdV4Lar@gyllingar
signature.asc
Description: This is a digitally signed message part.
Re: Debian LSB compliance
Didier 'OdyX' Raboud wrote: > Given > a) the work that certifying Debian would take; > b) the interest in having Debian be certified (I am yet to see any of >that interest); > c) the marginal interest by application vendors for the LSB; > > I'm leaning towards outright giving up. Agreed, spending further time on LSB compliance seems like a waste of time/resources at this point. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnmpqm7o.f39@inutil.org
Re: Debian LSB compliance
Le vendredi, 3 juillet 2015, 13.20:08 Mats Wichmann a écrit : > On 07/03/15 07:28, Didier 'OdyX' Raboud wrote: > > 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. > > The current distribution checker is actually quite easy to set up, > it's just a package to install and off you go, answer a few questions > through a web interface. Should you have the patience to fire off 10+ > hours of tests and then want to look at them. You would need that for > "compliance" which has never directly been a Debian goal, as you say. Fair enough, but then what? Let's assume we test 'stretch', our next stable release. Case a) Tests show that it is compliant so far, and by some magic trickery, this stays true until release day. In this case, we should apply for full certification, and use that as an "sales" argument. Case b) Tests show that it isn't: some problems might point to meaningful changes, but some others might not be fixable? We'd be non- compliant, and all that work would be a wasted effort. From what I understand (given the timescales), changing the LSB to be "whatever Debian as well as all other actors in the FLOSS world are _actually_ doing" is a painful, long and boring process, that the people involved in the LSB processes are only very slowly doing by themselves (no offense intended). The packages we currently have were built for LSB4.1, and the LSB5.0 just went out. Are there people out there interested in making the LSB relevant through certifying Debian 'stretch' for LSB5 [0]? Let's face it: given the current importance of Debian in the distributions' ecosystem, our decision with regards to becoming LSB5 certified (or not) could be decisive: if we commit to it, and establish efficient communication channels to push for LSB changes (eventually leading to a LSB5.1 == Debian strectch), then this /could/ make LSB5 somewhat more relevant than it ever was. If we don't, and instead outright "give up" on LSB support, then this might very well be a further nail in the LSB coffin. Given a) the work that certifying Debian would take; b) the interest in having Debian be certified (I am yet to see any of that interest); c) the marginal interest by application vendors for the LSB; … I'm leaning towards outright giving up. Of course, I could simply orphan src:lsb and be done with it, but I feel we'd be much better off with a src:lsb package that either does, or doesn't at all provide LSB5 certification: the middle ground that we've stayed in is helping neither Debian or LSB. So, are there any volunteers to make Debian LSB-certified? I'm likely to work on src:lsb during DebConf, so please make yourself known before then! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Debian LSB compliance
On 07/03/15 07:28, Didier 'OdyX' Raboud wrote: > 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. The current distribution checker is actually quite easy to set up, it's just a package to install and off you go, answer a few questions through a web interface. Should you have the patience to fire off 10+ hours of tests and then want to look at them. You would need that for "compliance" which has never directly been a Debian goal, as you say. To answer the level of questions you bring up (existence of required libs/interfaces/commands) you actually need just two simple tools - lsb-libchk and lsb-cmdchk. LSB has a repository which contains these at http://ftp.linuxbase.org/pub/lsb/repositories/debian/pkgs-5.0/ (or 4.1, or...) This is not to talk you out of your arguments, which make plenty of sens, just to inform that the basic level of checking is pretty simple. -- mats -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5596e068.1000...@wichmann.us
Debian LSB compliance (was: Re: Standard-producing bodies and Debian)
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.
