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

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

Control: severity -1 wishlist
Control: tags -1 wontfix
Control: merge 1020893 -1

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/

Hi Gioele,

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

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,

Hi Santiago,

What are your thoughts on this proposal?

Thanks,
Harshula

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.

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

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,