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. 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. > 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. >> 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. >> 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. > Debian stable updates do not, and pretty much never have, include only > security fixes. Exactly, which is why they should result in a VERSION_ID bump. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
