Bug#1038383: lsb_release: please add the ability to guess_release_from_apt()

[Harshula]

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

[Harshula]

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

[Gioele Barabucci]

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

[Harshula]

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

[Gioele Barabucci]

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

[Harshula]

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

[Santiago Vila]

unblock 1020893 by 1021663
thanks

El 18/6/23 a las 1:56, Harshula escribió:

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.

[Harshula]

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

[Gioele Barabucci]

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