Hi Luca, On Thu, Aug 01, 2024 at 04:54:20PM +0100, Luca Boccassi wrote: > 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.
I observe that Santiago has replied to each of them with patience and that he has presented relatable reasons for his choices. As you detail later, it seems that the corner stone of your complaint is that an unstable installation should have VERSION_CODENAME=sid rather than VERSION_CODENAME=trixie. Do you agree with this characterization? > 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. On a process level, the CTTE can only decide among available options. In this context available roughly equates the existence of a patch (or source package). Reading multiple bugs, I found disagreement on this approach, but no code that could be characterized as a reviewable solution. Another plausible way to interpret your mail is that you really ask the CTTE to override the base-files maintainer in claiming ownership of /etc/os-release in the base-files package request releasing the file to another package. Given that said file has become part of the essential interface, releasing it is subtle and warrants a more detailed look at how the take-over is supposed to happen. To me that process is too sketchy to consider at this time. > 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. Evidently, there are multiple conflicting requirements that various parties would like to see implemented. The base-files maintainer has made a compromise and argued in favour of his position. Said compromise encompasses an interpretation of the os-release specification that does not follow it to the letter. > 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). Please allow me to raise the question of what is the benefit of differentiating sid and trixie in /etc/os-release. I am inclined to agree that VERSION_CODENAME would be technically wrong in unstable, but we have a history of sometimes bending rules. For instance libc6 being Multi-Arch: same technically is a lie as multiple architectures share the same dynamic loader path. A strict interpretation would require us to remove Multi-Arch: same, but that would make much of Multi-Arch useless. Likewise, linux-libc-dev is currently declared Multi-Arch: foreign, which also is a technical lie. We also tolerate violations of Debian policy in exceptional circumstances. Given the arguments presented by the base-files maintainer, I kindly request more specific details on what use case is broken by being unable to differentiate testing and unstable. Conversely, I am unsure how to distinguish testing and unstable myself. Say I operate an unstable system and eventually decide that my ride is too bumpy and I prefer running testing, I may edit my sources.list and after a month or so my system will have reasonably converged to testing. At what point would my /etc/os-release change? Russ raised the question of how to represent a testing system that pulls some packages from unstable. > 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. Given the issues you experienced, would you be kind enough to reference some of them here? > 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 As far as I grasped from reading the bugs there are roughly two solution categories. One continues to install /etc/os-release as a conffile and uses the t-p-u mechanism to update it in trixie. The other category turns it into a configuration file constructing it from some maintainer script. I can relate to characterizing both as ugly. With my CTTE member hat lifted, I may also participate in design discussions and would like to propose a third alternative (although it might have been mentioned in the parts that I skimmed too quickly and hope that you can point to the earlier discussion in that case). Consider adding a new Debian binary package containing /etc/os-release with contents suitable for unstable. This package would use the dpkg-divert mechanism to avoid a conflict with base-files which would continue to install /etc/os-release with contents suitable for testing (even in unstable). We would mark this new package "Essential: yes", but have no other package depend on it. We would also file a permanent rc-bug to prevent it from migrating to testing. As a result, the set of essential packages as discovered by bootstrapping tools would differ between testing and unstable and the /etc/os-release would be diverted for unstable only. A significant downside of this approach is that all existing unstable systems would never install this package (and thus continue to be seen as testing installations) and all systems that were bootstrapped as unstable would be keep this package even if they were to be downgraded to testing at a later time (unless the administrator actively removes the new package). > 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. We have a disagreement about whether the information you intend to convey actually exists beyond the point in time where you deboostrap. If I debootstrap unstable and look at it a week later, it more closely represents testing than unstable. > 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. Conversely, we might consider that the os-release specification that is meant to cover the various aspects of Linux distributions is a poor fit for Debian and that its expressiveness is too limited to accurately represent the migration-based approach that Debian uses to assemble its releases. We might consider this a bug in the os-release specification and we may even disagree with the os-release specification upstream (aka you) about that. It all depends on how you look at it. > 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 > ). Thank you for referencing a practical effect. It is not clear how mkosi uses the Release field and why it is important to differentiate testing from unstable though. > 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. As far as I read the specification, no field is mandatory. This gives rise to another solution to come into compliance with the letter of the specification: Drop the VERSION_CODENAME from /etc/os-release just as the VERSION is already dropped. As far as I can see, all other fields have compliant values. > 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 think this needs agreement from the release team before moving forward. With my bootstrapping-hat, I would also like to see evidence of tests that this approach does not negatively impact debootstrap-like tools. (Russ gave a longer rationale on this, thanks.) > 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 the offer. Before asking you to do that work, I think there are a few actionable items for moving the disagreement forward: I'd like to better understand the problems caused by the imprecise implementation of the os-release specification as that aspect is still quite sketchy in your request. Your request actually includes a number of possible solutions with varying implications. Could you rank the various solutions according to your preference and express your reasons for ranking when it is not obvious? If your preferred solution requires the use of t-p-u, I suggest seeking approval from the release team before proceeding to implement it. In any case, my impression is that your request is not yet actionable on the CTTE side. Helmut
