Dear base-files maintainer,

this is a followup to #1008735 to provide 3rd-party software authors
with better clarity (and confirmations) about Debian's approach to the
information shipped in `os-release`.

A quick summary: `os-release(5)` is the only currently supported
cross-distro API to retrieve operating system identification data.

With this in mind, it seems correct, based on the content of the
`os-release` file shipped by `base-files`, to state that:

1. Debian has no concept of "release version" (codified in `os-release`
in `VERSION_ID`) for operating systems built using the software
published in the suites "unstable" and "testing". These operating system
instances just exist and have no version.

(For comparison, other rolling distros publish version IDs for
snapshots. For example openSUSE Tumbleweed uses a date like "20220926",
Fedora rawhide uses the upcoming version number "38".)

2. Debian does not desire to distinguish between OS installations based
on unstable and those based on testing using their codename (codified in
`os-release` in `VERSION_CODENAME`). The same string (the name of the
upcoming stable version) will be thus be used for both versions and it
should not be possible for 3rd-party software to distinguish between them.

(For comparison, the Release files in the archive use "Codename: sid"
for unstable.)

Is this a correct reading?

Aside from the current situation summarized in the above points, could
you please consider again the idea of having the suite name in
`VERSION_ID` ("testing", "unstable") and meaningful codenames in
`VERSION_CODENAME` ("bookworm", "sid"), at least to simplify the work of
3rd-party software authors?

Regards,

El 12/10/22 a las 17:42, Gioele Barabucci escribió:

That's correct. In theory, Debian bookworm will not be Debian 12 until
it's released as stable.

In practice, we put the correct version number in os-release a few
months before the actual release, so that everybody can test bookworm as
if it was already stable. This happens sometimes sooner and sometimes
later, you can check this by reading base-files changelog.

But this is done just a few months before the release and it's not
expected to be there for the entire life of the testing distribution.

Sometimes people report this as a bug, but at this time, it is not,
because it's too early.
 > [...]

It would be more accurate to say it in this other way:

We do not desire to distinguish between bookworm and sid based on the
contents of os-release from base-files, because as it's explained in the
FAQ, the base-files package is uploaded for unstable and later
propagates to testing.

If there is another way to distinguish between bookworm and sid based on
some other thing (for example, whatever information is present in the
Release file in the ftp archives that apt-get update retrieves, as you
point out), it might be desirable to explore those other ways to
distinguish between bookworm and sid. But not in base-files.

Sorry, no, I already did what I believe it's reasonable to do in
base-files. If there are things to improve, they should be done elsewhere.

In particular, making a bug in other packages to be blocked by this
particular bug in base-files, which I consider done, is not welcome.
Please don't do that.

Thanks.

El 12/10/22 a las 17:42, Gioele Barabucci escribió:

That's correct. In theory, Debian bookworm will not be Debian 12 until
it's released as stable.

In practice, we put the correct version number in os-release a few
months before the actual release, so that everybody can test bookworm as
if it was already stable. This happens sometimes sooner and sometimes
later, you can check this by reading base-files changelog.

But this is done just a few months before the release and it's not
expected to be there for the entire life of the testing distribution.

Sometimes people report this as a bug, but at this time, it is not,
because it's too early.
 > [...]

It would be more accurate to say it in this other way:

We do not desire to distinguish between bookworm and sid based on the
contents of os-release from base-files, because as it's explained in the
FAQ, the base-files package is uploaded for unstable and later
propagates to testing.

If there is another way to distinguish between bookworm and sid based on
some other thing (for example, whatever information is present in the
Release file in the ftp archives that apt-get update retrieves, as you
point out), it might be desirable to explore those other ways to
distinguish between bookworm and sid. But not in base-files.

Sorry, no, I already did what I believe it's reasonable to do in
base-files. If there are things to improve, they should be done elsewhere.

In particular, making a bug in other packages to be blocked by this
particular bug in base-files, which I consider done, is not welcome.
Please don't do that.

Thanks.

I added VERSION_CODENAME in base-files 12.3, and I have already explained
that from the base-files side, this is as far as we can go.

Release managers have always supported the idea that neither testing or unstable
are "releases" or have version numbers attached to them. If you don't really like
this, you should probably talk to them.

Thanks.

tags 1021663 + moreinfo
thanks

[ Note: This comes from #675731. I'm replying here because
this is where it really belongs ]

El 21/7/24 a las 11:36, Luca Boccassi escribió:
have not been so many bugs over the years.

There is a paragraph in /usr/share/doc/base-files/FAQ saying
testing and unstable are sides of the same coin. Most people
read it and realize that differentiating between testing
and unstable is not such an important issue. In some cases
(read below) it may be even counter-productive and harmful.

Moreover, for some time, we had a smart "lsb_release" command
which actually looked at the sources.list file (the recommended
approach).

Well, that's vague and imprecise. When reporting bugs, one usually
tells what one did, what one expected, and what one got.

I guess you simply expected VERSION_CODENAME to be "sid" on a system
running sid, but there are reasons why that's not reasonable or useful
and the FAQ attempts at explaining that.

This is unaccurate in several ways. You say that it's not useful for
testing, but that's not true. Also, you say that we need to make it useful
for unstable. Well, unstable is not a supported distribution, so that
would be at least subject to debate.
between testing and unstable. It may be the case that such software
is already broken to begin with.

If you find the above confusing, there is a very simple explanation:
some fields are to be read by humans, and others are to be read by scripts
and the like. The file debian_version historically reads as trixie/sid
because its contents end up being shown to the end user on login screens,
while the more recent VERSION_CODENAME has the value "trixie", as it's
to be read by scripts which are meant to work in a system running trixie.

[ At this point, I'll omit your split-os-release proposal from this quote,
it was already proposed by Gioele Barabucci and it was already rejected.
The funny thing is that you claim that looking at sources.list is ugly
and to solve your problem you make a proposal which is ten times uglier ].

No, I don't think putting os-release in a different package is a good idea,
but I can agree that this needs to be better documented in the FAQ.
More explanations follow.

The unstable distribution is surely a lot of different things for a lot of
different people, but among all those things, it's a staging area for the
testing distribution, which we also use "live" to help catch bugs before
they reach testing.

If we implemented your os-release proposal and somebody uploads a package for unstable which relies on VERSION_CODENAME having the values "bullseye",
"bookworm" or "trixie", the package will not work properly in unstable,
because VERSION_CODENAME would have a value which is none of those,
and users of unstable will think there is a bug in such package.

That's definitely not what we want. We want packages uploaded for unstable
to behave the same (or as close as possible) before and after they
propagate to testing, and for that purpose the value which makes most
sense for VERSION_CODENAME in both testing and unstable is the one it has
right now (trixie, or the testing of the time).

In fact, if your package or script works currently ok in trixie but needs to be different in unstable to work properly, your package will break sooner or later, because packages from unstable propagate to testing all the time.

For that reason, in general, it is a bad idea to target anything "for unstable".

And for that reason, that's something that we might better not encourage.

Your insistence in having a different os-release for testing and unstable
is like complaining that the code generated by a cross-compiler may
not be executed natively on the system it was generated. Of course it
will not work, it was generated by a cross-compiler.

I'm not saying that for some purposes it may be useful/nice to know the
"real" distribution that you are running, but not at the cost of breaking
the way testing and unstable work as twin distributions.

This means that no matter how much important it is for you to differentiate
them, you will have to achieve such functionality by other means other
than using os-release.

At this point it should be noted that such functionality *already* existed
in the past in the lsb_release command, and it worked well enough.
The current maintainer does not seem to be willing to restore the
old behaviour, but nothing prevents the old code from being packaged
again under a new name in a new package that you can use for your intended purpose.

As far as base-files is concerned, the issue now is just how can I document
this properly in /usr/share/doc/base-files/FAQ so that people are really
aware that testing and unstable are sides of the same coin. It is not nice
to see non-bugs resurrected (as you did) because people did not understand
the reasons they are non-bugs.

There is already a paragraph about this in /usr/share/doc/base-files/FAQ.
Do you have any suggestion to improve it, so that we can avoid this
discussion in the future?

Of maybe you would prefer to recycle this report and reassign it
as an ITP to create a package containing your desired script?
In this case I would gladly add a reference to the new package
in the FAQ once that such package exists.

Thanks.

They *ask* for different things, as in, different solutions are
brainstormed and proposed. But the underlying problem is the same
across all those (and more, actually), which is the title I picked: it
is not possible to distinguish a testing image from an unstable image.
That's the reason I merged and retitled - while submitters often
propose solutions, the thing that matters most is the problem being
addressed, and in my view it doesn't make sense to consider the same
problem multiple times independently and in isolation. Of course you
are entitled to rearrange bugs for your packages as you see fit, so I
will not change them any further.

Just as you are entitled to rearrange bugs of your packages as you see
fit, I am entitled to reply where and how I see fit. If I think some
information is worth being associated with multiple issues, I will CC
multiple issues. You are free to drop any CC from your own mails of
course.

And once again, the root cause is not being able to distinguish
between the two. The particular fields are one specific suggestion on
how to potentially fix that issue, and one that is not correct as you
already noted. The underlying problem is still the same though.

Same as above. Adding VERSION_CODENAME did not solve that problem at
all, as it is present in unstable too - in fact, by adding
VERSION_CODENAME=trixie to unstable, it made things _worse_, not
_better_, as now there is yet another piece of wrong metadata being
associated with sid images, that users have to know about and work
around manually.

The 3 CC'ed ones are the first ones I could find with a cursory look.
The sheer amount of Debian-specific ugly hacks that are around because
of this bug in base-files speaks volumes.

That FAQ is wrong, at the very least from the point of view of the
os-release specification. Once again, you can do:

debootstrap unstable a/
debootstrap testing b/

and then you have two different and independent images, running two
different and independent sets of packages, from two different and
independent archives, and no sensible way to distinguish them.

It doesn't matter what you write down in your own FAQ, the
specification is what matters. If you want to write a competing
specification, with different semantics and contents, and convince
other distros to adopt it instead of os-release, feel free to do so.
But what base-files ships is not a spec-compliant os-release metadata
file, and that's a bug in base-files.

That is not the recommended approach, that's a Debian-specific
horrendous and fragile hack (hint: you can have _both_ unstable and
testing lines in sources.list, with unstable apt-pinned at 1 or so,
and then your recommendation falls apart). LSB is dead, and good
riddance. We want to reduce these pointless and painful debianism, not
make them proliferate. We should promote Debian based on what it's
good at, not based on how much of a pain it is to use.

No, I expected to be able to tell if an image I am managing is trixie
or sid, and it is impossible to do so reliably. It is a problem that
exists only in Debian.

As an upstream author and maintainer of the os-release specification,
I can tell you with absolute certainty that it is in fact accurate.
The way base-files generates os-release currently in Debian is bugged,
and as per multiple bug reports has always been bugged. The wrong
metadata is conveyed to users. This is not a matter of opinions, the
spec is very clear.

Any software that deals with images, root directories, and whatnot.
And the only broken software here is base-files.
which is not unstable, it's something different.

Refusing to fix obvious bugs found by multiple users resulting in
horrendous Debian-specific workarounds that no other distro subjects
their users to, and the best justification you can find is that it's
"ugly to do uploads"?

This is a made-up strawman. There is no such package that I am aware
of. Please provide actual evidence, if any. I have never seen anything
like that, ever.

Once again, this is not about a package or script. This is about
identifying images.

Nothing is broken in the way testing and unstable work. Every other
distribution manages to do this just fine, it's only Debian where this
bug happens, and it's only because of this persistent refusal to fix
base-files, despite the many bugs being reported over many years.

And this is the bug. The purpose of os-release is to provide a
universal, distro-agnostic way to do that differentiation. This is not
something subjective or a personal preference: it's what the spec is
for. The implementation of the spec in base-files is buggy.

LSB is dead, and good riddance. We have os-release as the
specification to identify images exactly because we want a
cross-distribution, universal standard that doesn't require special
scripts to exist and be run, but a simple metadata read-only text
file. Adding yet again more Debian-specific ugly kludges is not a
solution.

These are all base-files bugs, because they stop cross-distro software
from being able to work. FAQs solve nothing. You cannot unilaterally
modify a Linux-wide specification via a FAQ and call it a day, sorry,
that is not how this works The implementation of the os-release spec
in base-file is buggy and needs to be fixed.

No, what I prefer to do now, given this is obviously going nowhere and
it has been more than a decade of stonewalling on your part, resulting
in a buggy implementation of a Linux-wide specification causing grief
for Debian users, is escalating to the CTTE to override you.

These bugs have now been escalated to the CTTE:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764