On Mon, Jun 17, 2024 at 02:24:18PM +0100, Luca Boccassi wrote:
> > IOW, I can't think of any situation where mapping VERSION_CODENAME to
> > osVersion would be a problem, and it's more stable. I would be happy
> > to
> > stand corrected, though!
>
> Please don't - these notes are there to be machine-readable, so the
> format needs to be sensible and common, so unnecessary deviations will
> be detrimental to the effort. This is sourced directly from os-release,
> which as Julian said is set at the beginning.
May I suggest that you change the spec then please? As written, it looks
like distributions are free to choose how to populate these fields,
rather than it being a mandatory mapping from /etc/os-release (given
that we provide that). Or, if it's just that you expect the version to
be orderable, perhaps specify that?
> The optimal thing to me would sound like doing an archive-wide
> (ignoring arch:all only) rebuild once os-release is changed at the
> beginning of the cycle (and again if it were to happen later, too), so
> that the change can be picked up. This also solves the problem of
> packages not being rebuilt. And it seems like a desirable thing as
> you'll be using the latest compiler, with the latest hardening fixes,
> and so on, so it would be a win/win.
This would be up to the Ubuntu Release Team to organise, but it would be
a very significant change in our development workflow and I don't think
it would be practical. Notably, Debian doesn't do this either.
> If this is not possible or desirable for any reason, then please just
> omit the field entirely. Anything parsing it needs to expect this to be
> missing anyway, for the rolling distros use case.
Ack. I was concerned before that omitting it would cause more problems
for ecosystem tooling, but given that you're saying it's fine, that
also sounds fine to me.
It might be worth you also adding this specific recommendation to the
spec for distributions that carry forward builds across releases such as
Debian and Ubuntu.
Robie
