Package: tech-ctte Dear CTTE,
This is an escalation requesting a ruling on the matter of several base-files bugs around its buggy implementation of the os-release specification, the most recent example being #1021663 and other instances that I could find with a cursory look being #1008735 and #675731. The TL;DR is a request to override the base-files maintainer, and enable moving os-release into a new, independent and separate source package, so that these bugs may finally be fixed, and Debian's os- release may finally be made compliant with the specification. Numerous attempts were independently made by many different people to try and convince the base-files maintainer to fix this issue, the oldest one linked above being 12 years ago, and they have all been rejected, as recently as today. The only course of action left is therefore asking for a CTTE intervention in the matter, as all attempts at mediation and negotiation over the years have failed. The os-release specification, of which I am an upstream author and maintainer, defines a distro-agnostic text-based metadata format to allow identifying Linux distributions images, root directories, trees and whatnot, without requiring distro-specific quirks, executables, binaries, scripts or workarounds. It has been adopted pretty much universally on Linux, including in Debian since 2012. It supersedes deprecated tools and specifications such as lsb_release and distro- specific files such as debian_release. Spec: https://www.freedesktop.org/software/systemd/man/devel/os-release.html With my upstream spec maintainer hat on, I am asserting that the base- files implementation of the os-release specification is buggy. This has always been the case, since the very beginning, as it can be seen in the oldest of the bugs linked above. The crux of the issue is that the way base-files implements the specification does not allow to distinguish testing vs unstable images, and worse than that, it recently started providing wrong and misleading information, incorrectly identifying sid as trixie (via VERSION_CODENAME=trixie). This has resulted in numerous downstream users, tools, scripts and code having to employ fragile Debian-specific hacks, such as trying to grep /etc/apt/sources.list in an attempt to catch "unstable/sid" or "testing" keywords, which of course is can break spectacularly, for example if apt is not configure in an image (which is normal in a read- only image-based system), or if both unstable and testing repositories are present, with unstable pinned via apt-preferences to 1. Other distributions do not have this issue, it is only a problem that Debian forces its users to deal with, causing grief and pain. The base-files maintainer provides broadly two categories of justifications for refusing to fix these issues. The first one is dismissing any proposed solution as "ugly", without really substantiating what it means - that is for example the case for multiple proposals in #1021663. The second one is pushing forward a philosophical explanation according to which testing and unstable are not actually different images, but they are one and the same (two sides of the same coin is the expression used). While that might be true in a philosophical sense, this is a practical matter, and it concerns only the os-release specification and its implementation. In such context, testing and unstable are different and independent images, built from different and independent archives of packages. For example, at any point in time you can do: deboostrap testing /tmp/a deboostrap unstable /tmp/b and if your shell history is lost, you have no reliable, stable, distro-agnostic way to identify what exactly /tmp/a and /tmp/b are. These, created at the same time, contain different packages and refer to different archives, so while from a philosophical point of view one might make one argument or the other, from the very specific, concrete and real issue of implementing the os-release specification, they are different releases and it must be possible to identify them as such, and wrong information should not be conveyed to users. There is also another common misunderstanding regarding what constitutes a rolling release, sometimes used to justify avoiding to fix these bugs. Again here such a concept from a philosophical point of view might be bent into meaning many different things, but from the point of view of the os-release specification, a rolling release is a release that will never have a +1 or a -1 version. From the os-release point of view, the fact that a distribution is updated often and gets a lot of new packages, that might break ABI/API, or that is not security supported, does not mean it is a rolling distribution. So unstable/sid is a rolling distribution, because there will never be a new version, it will always be sid. Trixie however is _not_ a rolling distribution, because there is a trixie-1 (bookworm) and there will be a trixie+1 (forky). The fact that trixie gets a lot of changes in this 2 years development period is orthogonal and independent, and does not qualify it as a rolling distribution, in the context of the os-release specification. In fact, there is a proposal to add an independent os- release field that qualifies a version as "stable", "lts" or in "development", that would be suited to mark testing as such. So it would be entirely appropriate to set VERSION_ID=13 in trixie's os- release right now. It is not appropriate to set VERSION_ID=13 in sid's os-release, now or ever. These issues are not just theoretical, and do not concern mere personal preferences or cleanliness or code quality or ugliness. They cause very real, very actual and very painful grief for Debian users, as evidenced by the multiple independent bugs with multiple independent reporters chiming in, and the multiple ugly hacks that have to be implemented as Debian-specific workarounds (the latest instance of which can be found at https://sources.debian.org/src/systemd/256.4-2/debian/tests/upstream/#L15 ). The base-files maintainer repeatedly, over numerous years, refused to fix these incompatibilities with the specification, citing personal preferences and interpretations, and the latest suggestion as per #1021663 is to override the lsb_releae maintainer and ship again buggy and deprecated lsb_release python scripts to try again to solve the problem in a Debian-specific way, parsing apt's sources.list. The point of a cross-distro specification is to perform its function reliably so that users do not have to employ distro-specific workarounds, so we are currently doing our users a disservice by shipping a buggy implementation, and require them to use deprecated and buggy scripts as workarounds. It would in fact be much better to simply not ship an implementation of os-release at all, rather than implement it wrongly based on reinterpretations. A concrete proposal that I can put forward is to move os-release away from base-files, into a new source+binary package, that can be managed independently, and can be updated to respect the specification it is supposed to follow. base-files ships code in maintainer scripts so requires changes and updates, and using a separate package allows to do only one upload per cycle to set the new metadata. base-files can then depend on this new binary package, which will ship only /usr/lib/os- release, its /etc/os-release symlink and no maintainer script. This package should be team-maintained on Salsa (as opposed as base-files that is individually maintained with no VCS). The os-release installed in sid's images would then be something along those lines: PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" VERSION_CODENAME=sid ID=debian And trixie's would be something along those lines: PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie RELEASE_TYPE=pre-release ID=debian With RELEASE_TYPE= changing to 'lts' immediately before release day. There are several different ways of having different content in sid vs testing, and some have been proposed in the latest bug linked above, I would be happy to discuss those details too if required. I volunteer to do the work to create and team-maintain the new package, and provide a patch to do the move from base-files. If requested, I am happy to do such work in advance so that you can judge based on something concrete. Thank you for your consideration. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
