Distinguishing Debian testing from unstable

I *want* to stay on testing though. That's been my main work setup for more than 10 years now. So why should I use codenames?

But once every 2 years, "apt upgrade" will change my testing system to have a different VERSION_CODENAME. That's incoherent and a violation of the concept of "identity" as you have described it, at least to the best of my understanding.

I think that writing things like this instead of presenting actual use cases hinders your chances of having your proposals accepted. Of course lwn comments are not very relevant for this. But I personally haven't seen a use case yet that shows it's useful to someone.

Yeah I read that. The example with the images is why I thought you were trying to solve either a dependency analysis problem or a content identification problem, and copying CODENAME to an image is insufficient for either of those use cases on not-stable Debian. That's why I proposed a solution that leverages existing metadata to try to solve those problems.

Let's try another of your examples. There's a systemd test script which has a use case for imprecise dependency resolving: we are running on some version of Debian, and we want to create a separate similar instance of Debian so that we can throw some code at it and see if it runs on a fresh install.

The goal is to test code built with an older version of CODENAME on an equal or newer version of CODENAME, to see if its dependencies are satisfied. We don't have to worry about whether this works, because dependency failures (along with any other kind of failure) are expected results of the test.

There doesn't seem to be an identification requirement for this use case. The image isn't distributed or reused and its only user knows where it is. In the event of a test failure, the developer would address the issue, build a new image against then-current CODENAME, and discard the old one.

There's an implied restriction on the time between uses of CODENAME: presumably the host runs apt update just before building the binaries for testing, and a few seconds or minutes later it runs apt update again as it builds the test image. So the two uses of CODENAME refer to similar content because they are close in time. It's not a robust dependency resolution mechanism--it can still fail if the CODENAME archive is updated the wrong way in between--but maybe rarely enough that it's not a problem in practice.

We want all this to be self-hosted, so the package building code runs on a system with testing or unstable in sources.list and tests against a similar version. Specifically those two configurations, plus any stable version which has CODENAME defined. Any other arrangement isn't considered and might fail.

The CODENAME hack is there because at one point the debian systemd tests reach a choke point where they communicate a single word to mkosi to tell it what image it should build, and that word might be either "trixie" or empty (meaning "sid"). So the hack picks sid if there's "sid" or "unstable" in sources.list (and yes, it's every bit as buggy as it sounds, especially if you're running testing but your Debian mirror has a domain name like "inside.example.com").

But...the channel here is far wider than a single word: mkosi gets a full config file and access to apt's configuration trees. It's already pulling in /etc/apt/preferences* which could interact in odd ways with a stock sources list. Why would we not simply push the other half of the apt configuration into mkosi? Replicating both sources and preferences will produce the expected result under a much wider range of conditions than the CODENAME alone does, and this method has the advantage that we never have to look at os-release. Unless I'm missing a grep, this hack on top of broken code is the only thing the systemd Debian packaging scripts use os-release for.

There's another example (obs-build) that is similar, which is similar to the systemd test cases, in the sense that it builds a product with a short usable lifespan. This is more obvious in the systemd case because it creates a system image that's used only once, but in the obs-build case the package isn't labelled with sufficient dependency information so it's inevitably going to become unusable.

These are excellent concrete examples of when it is inappropriate to use os-release and VERSION_CODENAME.

> You seem to be thinking that this is exclusively useful for dependencies purposes.

Can you blame me? The examples I can find, including those you provided, are dependency purposes.

The hardinfo example isn't a dependency use case, but as far as I can tell, that code translates non-standard os-release data into a different non-standard format, and imposes Debian-specific requirements on the data that are not requirements of os-release. I can see why someone who already has a collection of output from that code would want to keep the legacy output format alive, but it is not an example of behavior new code should follow.

> There are tons of use cases, some that we'll never know about.

This is noise. We are not omniscient and cannot predict the future. If we can't define who reads a label and what properties of the labelled object the label attests to, there's no way to know whether the object is labelled correctly for any use case, and no way to know how to implement an object which has a given value of label. If there are no specified behaviors for downstream users, we could simply write "orange" on the label and never change it again.

If someone comes along with concrete requirements in the future, and they aren't compatible with the labels we have now, they can start a conversation about implementing them at that time.

It seems that we have no shortage of concrete definitions already, both on the labels and on the objects. There's no need to introduce fictional new ones.

> Fundamentally, os-release is about the OS vendor tree self-identifying in a distro-agnostic way that can be relied to just be there and be usable and accurate for what it provides

This needs more definition to be useful. If you can explain why "orange" is not a correct self-identifying distro-agnostic identification, but "sid" is, that's a good start. Then we can work on accuracy: is a 4-year window of possible versions sufficiently accurate (probably not)? Do you really mean precision instead of accuracy (is plus or minus a week OK)? Is there a validity or stability window (identifier is to be used over the next hour, day, month, until EOL date, since 2003, forever)? Do you have some downstream consumer of the string that has requirements you need to satisfy (so what are those)?

Once the basics are defined, we can figure out what it means to distinguish between "sid" and "trixie". If I start with trixie, but upgrade libc or perl, is it still trixie? How much of bookworm can I upgrade before it has to be called something else?

Forget upgrades and sources for a moment. How many of the options I have as a user using only bookworm can I exercise before CODENAME's accuracy changes? If I install bookworm but replace systemd with sysvinit, iproute2 with net-tools, net-manager with ifupdown, and iw with wireless-tools, third-party networking software might consider "bookworm" to be an inaccurate VERSION_CODENAME. Now consider if i start with Wheezy and upgrade through jessie, stretch, buster, and bullseye to bookworm, but I never install the new packages and update all the old ones to bookworm's versions. Is it accurate to label the resulting system with VERSION_CODENAME=bookworm?

If we don't have these requirements--if it's OK to make substantive changes to the environment software may find itself in, without changing VERSION_CODENAME--then any value of VERSION_CODENAME could be correct, and software that makes or supports decisions based on VERSION_CODENAME is wrong.

If you believe we do have these requirements--that there's some threshold past which a system is altered such that its VERSION_CODENAME must change...well, good luck with that.

> without requiring special binaries or scripts or other hacks

This needs definition too. What's a special script in the context of 640+ lines of highly Debian-specific code that is only run on Debian? Why is it better to remove a hack on top of os-release than to remove the dependency on os-release?

> There are many uses that one might derive from such a system, and not all of them have to be useful to everyone for it to exist.

Forget everyone, and forget the other cases--at this point I'm trying to identify _anyone_ who might find a distinction between only the two options of testing and unstable useful for a reason that is not "misunderstanding the problem they're trying to solve" or "inventing a problem that os-release can be involved in solving."

You're already doing like 80% of the work. You need to have a standard "recipe book" for creating images (unless you're one of those "the sysadmin does everything manually" people, but those people mostly don't use images in the first place). All I'm suggesting is that you keep track of which recipe you used. It's one value, which is probably just an integer or UUID. Why is that difficult?

> Also, by self-identifying, metadata is automatically covered by cryptographic signature o f the artifact, so if this is used in a deployment system, it can be trusted, without the need to implement a sidecar metadata and its own out-of-band verification methods.

Pffft, that's ridiculous. As soon as you have two or more computers, and they're not all in the same physical trust domain (building, in most cases, or perhaps an entire physically-secured campus), you need certificates and signatures on absolutely everything that moves between them. If you rely on the image's signature, then the recipient has to blindly trust that you wanted this image, and not any other image, installed on this hardware. For that matter, the recipient also has to blindly trust that you wanted the installation to take place at all. What if some attacker calls InstallImageOnComputer (or whatever it's named) on all of your production serving instances at once? You'll have an outage, and it will be entirely your own fault for letting them do that.

So you have to sign a metadata sidecar anyway, and this is not a real objection.

The whole topic is about testing vs unstable.

Nobody is arguing against /etc/os-release.