Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
On 18/06/23 12:58, Harshula wrote: Perhaps the best option is to refer this to the Technical Committee to see if there's a way we can move forward? Hi Harshula, there are three open questions here: 1) should Debian provide a way to distinguish between the two similar-but-not-identical, rolling, ephemeral releases called "testing" and "staging" via /etc/os-release, the current cross-distro facility for this purpose? (I believe it should) and 2) is it acceptable to ask 3rd party software (e.g., ansible [1]) to deal with the fact that Debian is the only major distro that does not provide a cross-distro way to tell apart its two development releases? (I believe it is not reasonable) and 3) should the Debian packaging of lsb-release-minimal include an ad-hoc patch that extends it to use heuristics to guess a piece of info what Debian explicitly does not want to provide? (I believe it should not) I doubt that these issues are important enough to be worth the attention of the Technical Committee, in particular issue 3 (Debian stopped supporting LSB in 2015, there are way better cross-distro facilities). But if in your opinion these issues are important and you are willing to coordinate (off-BTS) the writing of a summary of this issue to refer to tech-ctte, I'll be happy to provide you with all the context and information I have. [1] https://bugs.debian.org/931197#37 Regards, -- Gioele Barabucci
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
Hi Gioele, From a user perspective, the transition from the previous Python based lsb_release to the new lsb_release contains this regression. A solution does not appear to be forthcoming after approx. 9 months of user reports. Perhaps the best option is to refer this to the Technical Committee to see if there's a way we can move forward? Thanks, Harshula
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
unblock 1020893 by 1021663 thanks El 18/6/23 a las 1:56, Harshula escribió: Hi Santiago, On 18/6/23 03:04, Gioele Barabucci wrote: One can use the mechanism discussed in section 5.14.3 of the Developer's Reference [1]: 1) Block the automatic migration via britney/excuses. 2) When a new version is released, dput two different versions: one into unstable and one into testing-proposed-updates. To reduce the amount of work needed for each update of `base-files`, `/etc/os-release` can be moved to package like `debian-version-info`, so the manual double upload must be done only once per release cycle. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#direct-updates-to-testing What are your thoughts on this proposal? I see it as an excess of over-engineering for very little gain. I could agree that it would be "nice in a general sense" for lsb_release to show "sid" when running sid, but we should never forget that sid is just a staging area for testing and sid is not even a "release" in strict sense. Also, a package in sid which does not propagate to testing is now considered a RC bug by Release Managers. Let's not introduce artificial bugs to fix "problems" which will never happen in a stable release, and, in general, let's not make things a lot more complex than they really need to be. I already told Gioele here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021663#12 that his blocking of any base-files bugs regarding this issue is not welcome, and I explained why, so I'm undoing the unblock now. Thanks.
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
Hi Santiago, On 18/6/23 03:04, Gioele Barabucci wrote: One can use the mechanism discussed in section 5.14.3 of the Developer's Reference [1]: 1) Block the automatic migration via britney/excuses. 2) When a new version is released, dput two different versions: one into unstable and one into testing-proposed-updates. To reduce the amount of work needed for each update of `base-files`, `/etc/os-release` can be moved to package like `debian-version-info`, so the manual double upload must be done only once per release cycle. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#direct-updates-to-testing What are your thoughts on this proposal? Thanks, Harshula
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
On 17/06/23 16:53, Harshula wrote: On 17/6/23 23:26, Gioele Barabucci wrote: I understand your request and I fully support having better OS information in unstable and testing (see my request to base-files in bug #1021663 [1]). Since package updates transition from unstable to testing, can you please elaborate on how this would be fixed in the base-files package? The automatic migration is not a straitjacket. :) One can use the mechanism discussed in section 5.14.3 of the Developer's Reference [1]: 1) Block the automatic migration via britney/excuses. 2) When a new version is released, dput two different versions: one into unstable and one into testing-proposed-updates. To reduce the amount of work needed for each update of `base-files`, `/etc/os-release` can be moved to package like `debian-version-info`, so the manual double upload must be done only once per release cycle. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#direct-updates-to-testing Regards, -- Gioele Barabucci
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
Hi Gioele, On 17/6/23 23:26, Gioele Barabucci wrote: I understand your request and I fully support having better OS information in unstable and testing (see my request to base-files in bug #1021663 [1]). Since package updates transition from unstable to testing, can you please elaborate on how this would be fixed in the base-files package? Thanks, Harshula
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
Control: severity -1 wishlist Control: tags -1 wontfix Control: merge 1020893 -1 On 17/06/23 13:54, Harshula wrote: The old lsb_release.py script contains the function guess_release_from_apt(). Can you please add similar functionality to lsb-release to fix the regression? Dear Harshula, I understand your request and I fully support having better OS information in unstable and testing (see my request to base-files in bug #1021663 [1]). However, fixing the deficiencies of Debian's `/etc/os-release` is not the job of this minimalist implementation of `lsb_release`. By the way, LSB is no longer an active project and all distributions, including Debian, stopped supporting LSB in 2015 [2]. Scripts and infrastructure relying on `lsb_release` should be ported to modern (and simpler) cross-distro facilities like `/etc/os-release`. Regards, [1] https://bugs.debian.org/1021663 [2] https://lwn.net/Articles/658809/ -- Gioele Barabucci
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
At the moment, Debian Testing: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux trixie/sid Release:n/a Codename: trixie The previous Python based lsb_release: testing --- $ ./lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux trixie/sid Release:testing Codename: trixie unstable $ ./lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux trixie/sid Release:unstable Codename: trixie
Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()
Package: lsb-release Version: 12.0-1 Severity: important Hi Gioele, The old lsb_release.py script contains the function guess_release_from_apt(). Can you please add similar functionality to lsb-release to fix the regression? Thanks, Harshula
