On Fri, 2 Aug 2024 at 17:07, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > That's yet another Debian-specific workaround. The point of this is, > > again, answering the question "what is this vendor tree" _without_ > > distro specific kludges. That's the entire reason for os-release to > > exist. If the answer at any point is "check os-release AND THEN run this > > distro specific set of scripts or binaries", then the answer is wrong, > > and the implementation of the spec is buggy. Again, one might say "I am > > ok with this being buggy because we gain X Y and Z in exchange", but > > buggy it is and buggy it will remain. > > This talk about "buggy" and "workarounds" didn't help me understand what > you meant, but I think what you're saying is that I'm right, you *do* only > care about the apt configuration, BUT apt is Debian-specific and figuring > out how it is configured is not something that can be done portably, so > you do want to use os-release as a proxy for that information because it's > a cross-distro tool. > > That makes sense to me. It's a fallible proxy and it will get a bunch of > edge cases wrong, but it's probably not possible to do better with an > equivalently simple tool.
Right, but one important correction though - it's not _only_ apt, it's _also_ apt. Apt is one of the common issues, yes, but it's not the only one. It is entirely valid to create an OS vendor tree without apt or its configuration, for a minimal read-only image deployment for a VM or a container, that you update with an image-based tool with A/B style partitioning, for example. How do you identify such a vendor tree? There's no apt. The answer on every other distro is: read usr/lib/os-release. In Debian it's: read os-release and pray the old gods and the new that it returns something identifiable, and otherwise just despair and take a wild guess. > Fundamentally, you want to change Debian's policy about testing to > complete the separation from unstable and treat it as a first-class > release in its own right in our metadata. Debian has historically not > done this and generally discouraged people from doing this (this is *not* > just Santiago's position; Santiago is correctly reflecting the previous > consensus of the project), but there's always been a fair bit of > controversy over that point, and I personally tend towards the side that > thinks testing can be usefully treated as a rolling release with very > substantial caveats and limitations. > > I do agree that it's often useful to be able to quickly determine if an > image is pointing to testing or to unstable. I see what you are saying, but I have to say that expressing it like that makes it sound like I am asking to flip the thing on its head completely, and do something new and unprecedented, but I'm really not? I am asking to add one line to a text file. I'm not asking to change a policy. Nothing else will change - all workflows, all usages, all intentions, all procedures, all tools, everything will be exactly the same before and after. Because you can already, today, build and install a testing image, run it, update it, manage it, use it for workloads, and never, ever get even a hint that something called "unstable" even exists. We know this happens, and it always has happened, and it will continue to happen. And the same is true for unstable. They each have their own section of the archive, which are independent from each other and fully complete on their own (as opposed to other things already mentioned like ubuntu-proposed or experimental or stable-proposed-updates). You can do 'debootstrap unstable' build an image and run it, you can do 'debootstrap trixie' build an image and run it, and you were always able to do so. So, I don't know, it seems excessive and scary to say it's a change in policy? No policy changes here, no? > > On Fri, 2 Aug 2024 at 04:00, Russ Allbery <r...@debian.org> wrote: > > >> Well, it's related to your example of the zoom package basing decisions > >> on the version number. If they had done that based on a version number > >> of testing, there's a fairly high chance that whatever decisions they > >> made would be wrong by the time the stable release happens, > >> particularly if they do that early in a release cycle. > > >> That said, I would expect most third-party non-free packages like that > >> to not care at all about anything in Debian until it reached stable, so > >> the chances of them doing that may be low. > > > Uh, I did not provide an example regarding zoom? Where's that from? > > Ugh, I'm sorry, I was reading a lot of bug history and completely > misattributed that message (and, for that matter, when it was sent). I > was thinking of: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91 > > which was from Kipp Cannon. My apologies for the confusion. Right, I can see things like that happening - that's both a symptom of a bug in zoom and a bug in Debian. It's a bug in zoom because VERSION_ID is not mandatory, and a rolling release like Archlinux won't have it. It's a bug in Debian because it shows that external developers are (rightly, in my view) less and less willing to cater to special snowflakes, and will use distro-agnostic tools and specifications every time they are available, and we are falling behind. The answer to a user reporting such an issue won't be "sure we will add Debian-specific workarounds" it will be "run a supported distribution, not Debian" > >> I am surprised that point releases don't change VERSION_ID, and now I'm > >> curious why that's the case. I was assuming, having not previously > >> looked at it, that VERSION_ID would match /etc/debian_release, but I > >> see that it doesn't and has only the major version. > > > It is correct as-is. VERSION_ID is meant to identify a release, not > > updates or point releases. A release as in, Debian Bookworm, or Fedora > > 40, or Ubuntu Noble, and so on. > > Why would you not want to identify point releases? This really surprises > me. It's fine to identify point releases. It's not what VERSION_ID is for, though, that's all I am saying. If you want to propose that a full version is included in Debian's os-release, that's fine! The spec intentionally allow any namespaced fields to be added by a vendor, so we could have something like DEBIAN_VERSION_FULL_ID=12.3 or something like that, if you think it's important to do so - I don't see any problem with it and I'd be happy to add it if the CTTE rules in my favour. > >> Regardless, security uploads do potentially create this problem, but we > >> also try pretty hard to not change major functionality in security > >> uploads in ways that may prompt someone to want to change behavior > >> based on that version. There is a window of possibility there, I think > >> it's sufficiently narrow to not worry that much about. It's at least a > >> much narrower problem than version numbers in testing. > > > See other mail. It is really not narrow at all, because of kernel > > upstream LTS updates. The upstream kernel quality of these branches is > > really, really low, and massive regressions sneak in at all times. The > > difference of behaviour between point releases is huge. > > I believe kernels are usually (not always, but usually) updated as part of > point releases, which is yet another reason why I am so baffled as to why > the VERSION_ID would not track point releases. They are updated via security too. This will happen more and more with the CNA change where they basically tag every commit with a CVE.
