On Thu, Aug 01, 2024 at 06:58:09PM +0100, Luca Boccassi wrote: > The TL;DR: ensure that the version of the 'os-release' package with > the content for unstable stays in unstable and never migrates, and the > version of the 'os-release' package with the content for testing goes > to testing either via a quick migration or via > testing-proposed-updates.
This also means that os-release NEEDS to be managed in a package that is easy to get bug free: Either automatically generated or so simple that it's impossible to get wrong. The "testing" version of the package that will be promoted to stable on release day will never be in unstable, thus bugs in that package will be fatal immediately. This in my opinion rules out the option of keeping this inside base-files, which is a complex package that I really want to see managed through the normal unstable-testing-stable mirgration process. > That's it. Of course if what you are saying is that you mix and match > a selection of packages from testing and unstable, well that's a > frankendebian - you can do that on any release (I have some testing > packages pulled in my debian stable laptop right now). Hence, on such systems os-release is ALWAYS wrong in one or the other way, hence the local admin is on her own here. I don't see that as a problem. > I could echo "ID=windows 3.1" into my local > /etc/os-release and nothing would stop me or fix it until the next > stable release. Not even automatically. /etc/os-release is a conffile, isnt it? Greetings Marc
