On Thu, 1 Aug 2024 at 22:52, Helmut Grohne <hel...@subdivi.de> wrote: > > 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?
Yes, _and_ testing should have VERSION_CODENAME=trixie at the same time, to be precise. I.e., the very core of the conflict is about whether being able to tell the difference between testing and unstable should be possible following the distro-agnostic os-release specification. > > 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. Well you know this better than me of course, but isn't this also something you can do? Decide between: 1) The os-release specification must be adhered to, and it must be possible to tell the difference between testing vs unstable, and each must be correctly identified by the respective metadata or 2) Testing and unstable can continue to remain indistinguishable, and both be erroneously identified as trixie Again you'll know better than me, but it seems to me rulings were made in the past that were along similar lines (eg: usrmerge) - there wasn't reviewable code there, no? > 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. Sorry but I do not think that is an accurate representation. First of all, the implementation of the spec is bugged, period - it's not about being pedantic about it, it's about being completely incompatible: sid is identified as trixie, and that is just plain wrong, and there's no room for interpretation, no matter how one might try to bend it. You might say that you don't _care_ that the implementation is buggy, you might even say that it is worth, nay _good_ it to leave it buggy - but buggy it is, if I create a sid image, it will never in a million years be trixie, and yet it says it's trixie. Secondly, I am not even sure what these conflicting requirements actually are? Could you please spell them out? If trixie was identified as trixie, and sid was identified as unstable, what compromise would be, er, compromised, precisely? Because the only practical objections I could find were based on the idea that implementations would be ugly or hard to maintain or so - as already mentioned, I am happy to relieve anybody else and take that hard and ugly maintenance burden for myself. What other actual problem would suddenly appear? What feature or advantage do we leave behind? How are things made worse for our users? > > 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. Again, this is not just some slight deviation, this is completely and truly bugged, as it says it's one thing while it's another. The benefit is the same as having os-release in the first place - to have a standard, Linux-wide, distro-agnostic way of identifying an image. Everyone can take any OS vendor tree, open usr/lib/os-release under it, and know which distro and version it belongs to. You can do that for every Linux distro that I know of, but for Debian you cannot, you have to employ Debian-specifc hacks on top of it, such as trying to grep apt/sources.list and hope only one set is present. The benefit is allowing users to drop all these painful Debian-specific kludges that they have to carry - I linked in a previous mail the very latest one that I had to add myself. This is a well known and widely reported pain point, that you'll find traces of in the weirdest places. Here's one I am well familiar with as the git history will show: https://github.com/openSUSE/obs-build/blob/master/build-recipe-livebuild#L138 This implicitly imposes a requirement on which sources can be used to build live-build based images in the open build service, because of this base-files bug. Fortunately at the time we didn't care about that, for external reasons, so it didn't cause troubles, besides needing to hack it. Here's a random one, first result found searching on Github: https://github.com/lpereira/hardinfo/blob/4c97625c5666fa5fc353e7cab322b09159e54ed4/modules/computer/os.c#L486 /* HACK: Some Debian systems doesn't include the distribuition * name in /etc/debian_release, so add them here. */ Note how it starts with HACK, all caps? This is what we subject our users to. This is what we are known for. What do we even gain in exchange? > 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. Exactly in the same way as you represent a stable system that pulls some packages from testing, or pins some packages to oldstable. Whatever version of the package that provides os-release wins, as that's the only sensible and reasonable conclusion to reach. And if you have built a frankendebian and it's weird or incorrect? Well, as always when you build frankendebians, you can do it, but you get to keep the pieces, and the incorrectness of os-release will be the least of your worries if history has anything to say about it. The fact that you can install base-files from stable in an oldstable release doesn't mean os-release is useless and should be dropped or broken. It serves its purpose in the normal and expected use case, when you have an image or vendor tree built from one archive and you want to be able to identify it. I could echo 'ID=Skynet' into my /usr/lib/os-release right now, and nothing would stop me or revert it. It doesn't invalidate the concept and utility of os-release as a specification implemented by distributions. This metadata file is not magic, and is not a package manager, it cannot guarantee that what it says always matches what's around it, if one is willing to muck with things. But that's not its purpose. Its purpose is: I have a normal, correctly built OS vendor tree, and I am able to identify what vendor and version of the tree it is, without needing special hacks, workarounds, special programs, scripts, or hoops to jump through, whatever the distribution might be, whatever the vendor might be. Everyone else does this correctly. > > 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? Apart from what shared above and below, "Oh look, a DDI ( https://uapi-group.org/specifications/specs/discoverable_disk_image/ )! I wonder what it is?" $ sudo image.raw Name: image.raw Size: 3.6G OS Release: NAME=Fedora Linux VERSION=40 (Forty) ID=fedora VERSION_ID=40 VERSION_CODENAME= PLATFORM_ID=platform:f40 PRETTY_NAME=Fedora Linux 40 (Forty) ANSI_COLOR=0;38;2;60;110;180 LOGO=fedora-logo-icon CPE_NAME=cpe:/o:fedoraproject:fedora:40 DEFAULT_HOSTNAME=fedora HOME_URL=https://fedoraproject.org/ DOCUMENTATION_URL=https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/ SUPPORT_URL=https://ask.fedoraproject.org/ BUG_REPORT_URL=https://bugzilla.redhat.com/ REDHAT_BUGZILLA_PRODUCT=Fedora REDHAT_BUGZILLA_PRODUCT_VERSION=40 REDHAT_SUPPORT_PRODUCT=Fedora REDHAT_SUPPORT_PRODUCT_VERSION=40 SUPPORT_END=2025-05-13 Use As: ✓ bootable system for UEFI ✓ bootable system for container ✗ portable service ✗ extension for system ✗ extension for initrd ✗ extension for portable service RW DESIGNATOR PARTITION UUID PARTITION LABEL FSTYPE ARCHITECTURE VERITY GROWFS NODE PARTNO rw root 02d1fb3a-d58c-4be9-a165-4e1b33590… root-x86-64 btrfs x86-64 no yes /dev/loop0p2 2 rw esp abe612e8-6f83-4f1f-ad34-b82204c26… esp vfat - - no /dev/loop0p1 1 "Fedora 40, cool. Oh look, another DDI! I wonder what this one is instead?" $ sudo systemd-dissect image.raw Name: image.raw Size: 9.0G Machine ID: 341eb96eb8094d8a93e700d9ba42c68c OS Release: PRETTY_NAME=Debian GNU/Linux trixie/sid NAME=Debian GNU/Linux VERSION_CODENAME=trixie ID=debian HOME_URL=https://www.debian.org/ SUPPORT_URL=https://www.debian.org/support BUG_REPORT_URL=https://bugs.debian.org/ Use As: ✓ bootable system for UEFI ✓ bootable system for container ✗ portable service ✗ extension for system ✗ extension for initrd ✗ extension for portable service RW DESIGNATOR PARTITION UUID PARTITION LABEL FSTYPE ARCHITECTURE VERITY GROWFS NODE PARTNO rw root 7214d0b9-9b02-492d-b6db-af983c74c… root-x86-64 ext4 x86-64 no yes /dev/loop0p2 2 rw esp b5626e44-b572-4315-ab82-3ba507126… esp vfat - - no /dev/loop0p1 1 "Ah it's Debian Trix..." $ sudo build/systemd-dissect --copy-from image.raw /etc/apt/sources.list /tmp/sources $ grep Suites /tmp/sources Suites: unstable Suites: unstable-debug "Oh wait no, it's Debian Si..." $ sudo build/systemd-dissect --copy-from image.raw /etc/debian_version /tmp/debian_version $ cat /tmp/debian_version trixie/sid "Oh no, wait, it's... both?!" > > 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. To be pedantic, please note that /etc/os-release is a symlink, not a conffile. The real content is in /usr/lib/os-release. I personally don't think it should be done via maintainer scripts if possible, it should simply ship fixed content. The fewer runtime moving parts we have, especially in the essential set, the safer and the better, and I think your experience should match here. Things working great in image-based systems is important to me. I do not find using t-p-u to update the content ugly at all to be honest, it's there to be used as a piece of infrastructure. I do not see anything wrong with using it? What would be the actual issue? And anyway as already mentioned, I am fine with taking the burden of such ugliness upon myself, so that nobody else has to be subjected to it. Win/win! > 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). The downsides you have mentioned are significant already, and also as you know I very strongly dislike dpkg-diverts, but that's my problem. However, having complex maintainer script machinery in the essential set is everyone's problem, as it can and will break, and as above, I am sure it is best avoided. This still requires blocking the migration of a package, so it does not seem to me it provides any advantages over simply having an os-release binary package pinned to unstable, with no maintainer scripts, and just the content appropriate for unstable inside it. It still requires overruling the base-files maintainer. What would be the difference/advantage over the other approach? > > 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. I don't think so. It is unstable, one week out of date. It's not any different than running "debootstrap bookworm" and checking back X weeks later, after a point release is available - it will be outdated, but still bookworm, and still one apt update; apt upgrade away from being up to date again. Same for unstable: if it's a week old, after you apt upgrade it, it will be on par again. It will not magically become testing by itself. If you debootstrap unstable today and check back again in a year, it will not be stable trixie, it will be outdated unstable, and an apt upgrade will make it an up to date unstable. As above, os-release is not magic, and it is not a package manager. It cannot guarantee that things are up to date, or weren't manually broken somehow - that's just impossible. Its job is, given a normal and correctly built OS vendor tree, tell you what that tree is at the point it was created/last updated/whatever. An unstable tree is still unstable even if it's old. And if you build images and you want to identify _when_ it was built? We got a field for that! BUILD_ID= can be set to a timestamp for example. Then your ID=debian VERSION_CODENAME=sid BUILD_ID=20240802T0017 triplet in your tree tells you everything you need to know. Of course the latter is for image build tools, not for packages to ship. > > 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. Sounds good to me, then if it's a poor fit please rule against the base-file maintainer shipping an os-release file and force him to drop it entirely. That would be great. So then I can take it over from my packag... wait, did I say the quiet part out loud? Joking aside, there's nothing special about Debian here, it's just like any other distribution, most others have testing pockets too - Arch has them, SUSE has them, Ubuntu has them. Heck RHEL has an entire separate distro as a testing pocket! And yet they manage just fine to correctly implement the os-release specification. Our idiosyncrasies do not make us special and do not justify bugs. This is a bug in Debian's implementation, which says that X is Y, in exchange for... nothing in particular, it's just a bug, nobody wins anything from the current situation. > > 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. It's an image builder tool - it builds images, so it needs to know _which_ image to build and in this case, I need it to build a guest that matches the host - do I pull from testing or unstable? Which one is this? Ah it says trixie, so I can use the trixie repository and... oh wait now everything is broken because it was actually sid and a transition was not finished so I got a broken image. Try again next week? Because it's not just standalone images, but images based on other images (ie, sysext: https://uapi-group.org/specifications/specs/extension_image/ ). If you cannot identify an image, what the heck did you just build? And against what? And what do you base this other one on? Nobody knows. And then the hacks begin. > > 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. Yes, and that solves the "wrong information given" problem (which is new, VERSION_CODENAME was introduced somewhat recently in base-files), but does not solve the "cannot identify image without horrendous hacks" problem, so the implementation is still buggy - less so, but still buggy. The point of the spec is to uniquely identify an image, and if you are Arch and don't do releases then of course you don't specify the release codename (there ain't one), so the field is optional to cater to those use cases. It's not optional to cater to the "distribution is held together with duct tape and prayers" cases, I'm afraid. And if you don't implement the spec to enable its purpose of identifying vendor trees, why implement it at all? > > 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. Sure, and as mentioned elsewhere the version number is not the important bit and can be omitted if preferred. There's other fields that are better suited to identify release vs development stages, but it's not too important, and either way works. > 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.) Sorry, I do not follow - how would this impact debootstrap negatively? It's just a package with a single file? The only part to decide is what pulls it in and yeah that should be compatible with debootstrap of course. > > 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. I think I have shared enough examples of the hacks it forces one to use above, but the biggest bug can be seen by simply doing this: $ debootstrap sid /tmp/sid $ grep VERSION_CODENAME /tmp/sid/usr/lib/os-release <surprise!> > 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? The best and easiest solution is what I shared in a previous mail: a binary os-release package built from a new os-release source. It ships only /usr/lib/os-release and the /etc symlink, no maintainer scripts, no dependencies, no moving parts. Version 12345, which matches the combination of my luggage, will be in unstable with content: PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" VERSION_CODENAME=sid ID=debian RELEASE_TYPE=development and prevented from migrating via the preferred mechanism by ftp/rt. Version 13 will be in testing via testing-p-u with at least content: PRETTY_NAME="Debian GNU/Linux trixie" NAME="Debian GNU/Linux" VERSION_CODENAME=trixie ID=debian RELEASE_TYPE=development and possibly the version numbers if rt wants to, if not it gets added with the new upload at release time to drop the development bit. Post-release, a new upload is done for forky - rinse and repeat. No moving parts, no switcharoos, no juggling of flaming swords. The second best, in case t-p-u is not usable for any reason, is what I shared in the older email. Same as above w.r.t content and structure of the package, but at the beginning of each cycle a new version with the content appropriate for the new codename is uploaded to unstable with urgency high (and if rt is amenable with a hint to migrate the same day), and after migration another upload is done to restore the content for sid, and pinned again with the preferred method. Rinse and repeat. This requires more uploads, and one day every two years sid will have the wrong metadata. Still better than having the wrong metadata every day forever. After that I guess there's the maintainer scripts options - either the one you suggested above, or others. Not a fan: moving parts in the essential set bad, fixed package content good. Then further below, I guess I could start changing image build tools to adjust the content behind the maintainer's back. When building an unstable image in debootstrap, I know I am building unstable, so I could change debootstrap to fix the content of os-release after unpacking. Every other image builder tool should have to do the same, though, and worse, it would fight with dpkg as the content wouldn't match, and would be overwritten on updates, so I'd have to mark it as immutable. Really a bad option. Doing nothing would be the worst option of course. At that point, mandating that the base-files maintainer drops it and nobody else ships it would seriously be a better option. Then we can instantiate it in image tools, without conflicts with packages. It will be painful as there are millions of image builders, and the debian-specific hacks would have to be moved there by each and every one of them, but at least the content would be finally correct, which beats the current situation. > If your preferred solution requires the use of t-p-u, I suggest seeking > approval from the release team before proceeding to implement it. Sure, that was the idea. > In any case, my impression is that your request is not yet actionable on > the CTTE side. Besides what I provided above, is there anything else required to make it actionable?
