Hi again Keld, and sorry for the delay, Le samedi, 17 octobre 2015, 19.26:05 Keld Simonsen a écrit : > On Fri, Oct 16, 2015 at 03:43:15PM +0200, Didier 'OdyX' Raboud wrote: > > Le jeudi, 15 octobre 2015, 22.23:14 Keld Simonsen a écrit : > > > Would it be possible just to preserve the current LSB support, > > > just like many other distros do, and what is done in Debian 7.8? > > > > What is your precise use-case? > > Well, there are different considerations. > > I am associated with ISO/IEC JTC1/SC22, and their effort to update > the ISO 23360 LSB standard. For that effort it is good to know > what level of support LSB has in the various distributions.
The "level of LSB support" that Debian support has never (or regularly, AFAIK) been thoroughly tested, so having anyone do that would be great. Roughly, there are 3 main things LSB asks for: 1) library compatibility 2) lsb-* packages, as "compatibility-guaranteeing" layer 3) FHS Debian is adapting 3) FHS freely (aka has some exceptions to it), never actively checked for 1), and the "dropping" of 2) is just an explicit acknowledgement of these two facts. You could check for 1) in Debian stretch by using the lsb-* packages from the Debian lsb source in jessie, or from the version just before the drop. > I am myself doing a small Linux distro, keldix, which has not yet > been that succesful, but one of my ideas is to make most of the > packages dependent on LSB, so they can be used with other distros. I, for one, don't think LSB is the correct tool for sharing applications across distributions. (Recent) history has rather shown that the original tarballs is a much better compatibility layer. > I would like Keldix packages to also be useable with Debian. What would be these packages? I see two big clusters here: a) Either they are free software, and therefore are, or should/could be packaged for Debian directly. Having these available as LSB packages only would be novelty: there are not a lot of precedents, despite the long existence of the LSB: most free software projects are packaged for multiple distributions (and often multiple versions thereof) instead. b) Either they are not free software, in which case LSB _would_ make sense, but the historical cases (Skype comes as an example) have not taken that path, but rather the identical as above: packaging happens for multiple distributions (or big categories: deb-based, rpm-based, for example). Could you bring forward some examples of Keldix packages that would justify for Debian to keep its LSB package compatibility? Note that I'm not trying to corner out this particular distribution, I'm genuinely trying to find whether there are solid arguments in favour of Debian putting work into its LSB support. > > The other problem is that there is (very) close to zero available > > manpower to maintain the "current LSB support" available in Debian; > > volunteers welcome! > > Yes, I have read most of this, and also the mail on the lsb-discuss > list. I am a not-so-active participant in the LF LSB WG. > > What would it take to become a DD, to maintain the LSB package? One doesn't need to be (or become a DD) to maintain the LSB package: maintainership can happen without these rights, see the following links: https://www.debian.org/doc/manuals/maint-guide/ http://mentors.debian.net/ … Note that in the case of a non-DD maintainership (which is, per se, perfectly fine), package uploads to the Debian archive still need to be signed by a Debian Developer, and this one is to be found: I don't intend to upload src:lsb packages that re-introduce these compatibility packages back in the archive. > I understand that there is already a package, and I installed > it on one of my Debian 7.8 systems. > > My understanding from the LF LSB people is that the testing > of LSB has become easier, with LSB 5.0. I would be happy > both for the ISO effort and the Keldix LSB effort to have support > for what the current package suppports 2.0 - 4.1 - as this is also > what is supported in a number of other major distros. The action taken was to remove the compatibility packages [2) above], but all libraries should be there: the argument is that having 2) while 1) is not checked doesn't carry the value the LSB intends to put in these compatibility packages. Feel free to investigate and gather forces around reviving these compatibility packages: I will not stand in the way (but I don't intend to put work myself). Cheers, OdyX
