On Thu, Aug 01, 2024 at 11:51:45PM +0200, Helmut Grohne wrote: > 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?
Probably never since the os-release version in unstable would always have to be higher than the one in testing to not confuse dak. But alas, such an unstable-going-testing system will probably never be a "true" testing system since it will continue to keep packages that were removed from testing but not from unstable. Therefore, after the system has "reasonably converged" to testing, the local admin (you) would have to compare package lists anyway, and at this stage an apt --force-downgrade os-release or its working equivalent would be in order. > Russ raised the question of how to represent a testing system that pulls > some packages from unstable. That would stil be a testing system in my opinion. One of the core (mis)features of testing is that you don't get as speedy security support as you get in stable or unstable in most cases. This should be automatically distinguishable. Using apt-pinning it is possible to have a system misrepresent itself in most arbitrary ways, so if you want to be really sure you'd need to look at the versioned set of installed packages, but that's the pain you asked for yourself. > > 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? For example, having ansible playbooks that support testing becoming stable without breaking the systems or having to do in-sync changes to the inventory is unnecessarliy hard and error-prone. > 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. Not quite, it would have packages that are not in testing. And if upgraded, it would upgrade von unstable. > 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. I would expect from Debian to work constructively with the os-release specification upstream to adapt the specification that it might be a better fit for Debian some time in the future. If we divert from the specs here, distribution independent tools (like ansible, python, puppet etc) are unlikely to go along and special case Debian. > 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. That would make the file even less useful than it it today. A classical lose-lose solution. Please don't do that. > 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. Configuration Management, CMDBs, both in heterogenous fleets, using standard software that isn't willing to specialcase Debian. Greetings Marc
