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.
[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).
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.
> 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.
> 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.
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.
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).
This problem also applies to codenames, which I've seen used in Puppet
rules as well (more often than version numbers, in fact), so we already
have this problem since, as you pointed out when opening this bug, the
current base-files os-release file declares unstable and testing to be
trixie. To be clear, although I understand why Santiago made that change,
I have a similar worry about that decision.
Anyway, I don't know how much we should care about this, particularly
given the RELEASE_TYPE addition. That's why I said it was a worry, not a
blocking objection. The most mistake-resistant approach would be to give
testing some *other* code name that isn't trixie, and only give the code
name of trixie at the time of release, but that's also weirdly different
from how we use codenames in the archive structure and I am probably
overthinking this.
> What do you mean?!! It's right there!
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
> ...ok, ok, it's there now because I just merged it and regenerated the
> docs :-P
Thanks! This looks good to me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
