On Fri, 2 Aug 2024 at 04:00, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > It could be a dependency of something else, or it could be marked as > > essential itself, given the content is a 5 lines text file and a symlink > > it shouldn't be too hard to figure out an acceptable way to ensure it > > ships everywhere. It doesn't have to be related to base-files at all, it > > was just the first thing that came to mind. > > Given that it's included in base-files now and base-files is essential, I > believe it has to continue to be provided by an essential package, unless > we want to try to do the work of figuring out if os-release can be removed > from essential (and I would not be eager to do that). > > Since it is part of the essential set, though, I'm not sure the dependency > from base-files is actually needed (but also it may not really matter). I > think dependencies between essential packages are only really used during > the bootstrapping phase, and presumably os-release is not needed by > bootstrapping. > > Anyway, I haven't done any work in this area of Debian so I'll leave this > for other people with more relevant expertise to comment on.
Yeah it really has to be part of the essential set, it's just expected to be there in the minimalest of barest vendor trees. Priority: essential is probably the easiest. > [version numbers] > > The really important part is adding different and separate codenames, so > > that a testing image can be reliably and univocally distinguished from a > > sid image, and VERSION_CODENAME is enough for that, the version number > > is cherry on top. > > Like Santiago, I admit to not finding this use case compelling. Most of > the reasons why I might imagine someone would want to do this sound like > misunderstandings of how Debian works, given that in many cases, excluding > the apt configuration, today's unstable image is next week's testing image > without changing a single byte on disk. In other words, in the cases > where this does make sense, I feel like this desire is usually a proxy for > "what package pool will *new* packages for this image be drawn from," and > using os-release to guess at that information seems at least a bit > questionable. If what someone cares about is apt configuration, it seems > better to get that information from apt directly, not via a fallible proxy > (and maybe we need a better way to do that). 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. apt might not even be installed or configured in an otherwise correct and minimal read-only OS tree. It's not just about your laptop or your server, it's about building, running, stacking and identifying many types of images - bare metal, virtual, container, chroot, you name it. Please see examples in my other email to Helmut. > However, it doesn't seem obviously *bad* to do this either, and I trust > that you have reasons why you think this is important. > > > But this example seems a bit too tortured to me. > > 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? > > And secondly, that same strawman > > straw man (noun) > > 1: a weak or imaginary opposition (such as an argument or adversary) > set up only to be easily confuted > > This is the sort of thing I was talking about when I said insults. I'm > not sure if you're using this term with some non-standard definition > (believable, since I was using this argument in the opposite way from how > one would use a straw man), but the normal implication of calling my > argument a straw man is that I was arguing in bad faith. This comes > across as weirdly aggressive and makes these discussions unnecessarily > annoying. I admit I don't really pick up the Oxford dictionary every time I have to write an email, as there's not enough time in the world. I meant it as something like "example constructed during an argument that you cannot find in the real world". And look, I live in Scotland. When I'll actually mean to insult you, _you will know it_, without subtleties or hidden implications, so don't worry about it, ok? Hope this helps. Probably not. > > can be applied to stable, as we do point releases and security uploads. > > 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. > 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. Debian stable updates do not, and pretty much never have, include only security fixes. I do the same for systemd btw, it's not just the kernel: I regularly push systemd LTS updates to p-u, and it gets lots of generic bug fixes, and sometimes regressions do sneak in, although I like to delude myself into thinking it's better than the upstream kernel LTSes. > I'm not sure how important this is, and all the options have obvious > problems. I just know that I've seen a lot of code that uses version > numbers or code names this way, mostly in things like Puppet rules. Most > of the time people will probably get this right, but there are some > obvious potential mistakes such as coding a condition that says 13 behaves > the same as 12 (but the eventual release won't) or that 13 always behaves > in some new way (but testing systems that weren't upgraded to the released > version 13 don't and instead behave like 12). As mentioned in the other mail, the version number being present or not is actually a minor side issue, and it's fine either way, really. It's ok to add that at release time, if there are concerns about it, as it's not crucial to the core issue at hand, which is correctly identifying testing vs unstable images.
