Hi Santiago,

There have been many bugs over the years, and this issue keep biting.
Jut fell into it yet again.
Please, let's fix this, once and for all. os-release is the Linux
standard for identifying images, and we need to make it useful for our
users for testing and unstable too, not just for stable.

Currently in unstable/testing os-release contains:

PRETTY_NAME="Debian GNU/Linux trixie/sid"
VERSION_CODENAME=trixie

And debian_version contains:

trixie/sid

This is confusing and breaks all the software out there that needs to
distinguish between releases. And yes, they are different releases, as
the archives are different and separate. And when we create an unstable
or testing image, we choose one OR the other, not both, not either.

debootstrap unstable

or

debootstrap testing

Then after creating the image, we lose the ability to figure out which
is which, and have to resort to ugly hacks like grepping in
/etc/apt/sources.list, praying that it doesn't contain both
repositories.

This needs to be fixed. Here is a concrete proposal:

Move os-release and debian_version to a separate source package, in a
separate binary package, that base-files will depend on.
At the beginning of a cycle, upload os-release containing, for example:

VERSION_CODENAME=trixie
PRETTY_NAME="Debian GNU/Linux trixie"

and debian_version:

trixie

Give it urgency=high and let it migrate quickly. Then, upload again
immediately, with:

VERSION_CODENAME=sid
PRETTY_NAME="Debian GNU/Linux sid"

and debian_version:

sid

and file an RC bug on it to stop it from migrating.

At the end of the cycle, repeat and add the VERSION_ID and other fields
if you want to only add them on release day.

With 2 uploads every ~2 years, the problem is solved, unstable can be
identified as unstable, and testing can be identified as testing. For
~4 days in a 2 years period, unstable will have a wrong identifier.
Compared to the current situation when it is always wrong, we can live
with it I am sure. It can be reduced to 2 days and 1 upload if we
immediately add the full next-release os-release content at the
beginning of the cycle.

If you do not have the time to work on the new package, as the upstream
maintainer of the os-release spec, I volunteer to take care of it, if
you wish it.

-- 
Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to