Hi Santiago,
thank you for responding.
On 22.08.24 15:54, Santiago Vila wrote:
El 22/8/24 a las 15:27, Lee Garrett escribió:
The following integration test in the ansible package is an example that
breaks when VERSION gets removed from /etc/os-release in the release cycle:
(ansible_distribution == 'Debian' and ansible_distribution_version is
version('8', '>=')
Link to the upstream source:
https://github.com/ansible/ansible/blob/5ab5f2348798dc3b9325573d1427b76ca8295386/test/integration/targets/service_facts/tasks/main.yml#L29
In practice this means that autopkgtests for the ansible package start failing
after a release when the VERSION variable gets removed.
The os-release spec itself says VERSION may or may not exist. Therefore it's
wrong
to rely on its existence.
That is technically correct, not really the question though. The question isn't
if it may or may not exist. The issue is that stable releases include it, and
testing/unstable don't include it all the time. This bug specifically asks to
include the VERSION* variables always (although the discussion got sidetracked).
I believe /etc/os-release should be set VERSION unconditionally. In the
absense of those fields I would assume its an ancient release where
/etc/os-release was not shipped yet.
Debian Release Managers have always opposed to testing or unstable having a
"version".
This comes from the time where a CD vendor started to distribute the development
version of Debian at the time, which was going to be Debian 1.0, before it was
finished.
After such incident happened, we started to use codenames. This means that
Debian
trixie, strictly speaking, will not be Debian 13 until it's released as stable.
(In practice we add version numbers a few months before the release, because
stable
is a snapshot of testing at the time of release).
Yes, that was one instance 28 years ago. A lot of things have happened since.
/etc/os-release didn't even exist back then. Also, /etc/lsb-release is not the
same conceptually as /etc/os-release, they only superficially serve similar
purposes. The latter is supposed to provide as much machine-readable information
about the OS to external programs as possible.
To summarize, in this bug report alone this breaks/complicates setups where:
- users testing their ansible playbooks on the testing release
- ansible autopkgtests in Debian
- CI tests for LinuxCNC
- mesa builds for Witold
- upstream kernel builds
- Using upstream zoom packages
In many cases VERSION_ID is used to check for a minimum release version. Not
providing that complicates things a lot. Among the use cases is CI testing code
against Debian pre-releases, which in practice simply doesn't happen. I believe
it would benefit Debian greatly if we'd help towards that.
For example, Ubuntu sets for their upcoming release following values:
PRETTY_NAME="Ubuntu Oracular Oriole (development branch)"
NAME="Ubuntu"
VERSION_ID="24.10"
VERSION="24.10 (Oracular Oriole)"
VERSION_CODENAME=oracular
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/";
SUPPORT_URL="https://help.ubuntu.com/";
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
UBUNTU_CODENAME=oracular
LOGO=ubuntu-logo
As such, I propose to set the following:
VERSION_ID="13"
VERSION="13 (trixie)"
additionally to the existing values.
It's also important to point out that every other major distro sets those values
in their pre-releases (Ubuntu, Redhat, Suse, CentOS, Fedora) without problems.
Debian is the outlier here that ends up needing extra workarounds, or being ignored.
If you want to change such a long-standing practice, you should *really* talk to
Release Managers, not to me.
Can you point me to a case where the release managers reverted or rejected such
a change to /etc/os-release? I'm especially interested in the arguments against
setting those machine-readable values in /etc/os-release.
Please stop reopening this bug, it's a wontfix. If you have a good suggestion
to improve how this is documented, please do so in Bug #1021663 which is
still open.
I'm fine with the wontfix (if you intend to not fix the problem), but I believe
it should stay open, as the original problem is not fixed.
I don't think #1021663 a good place to continue discussion, as that bug is
related to distinguishing testing and unstable, which this bug is not about.
Thanks.
And thank you for taking the time to write back!
Cheers,
Lee
