Stephen Dowdy writes:
> On 11/16/19 1:35 AM, Julien Cristau wrote:
> If i could interject here... I haven't followed the entire thread from
> start-to-finish, but
> my main concern here is the fact that somewhere 'lsb_release -rs' got broken.
> This has ALWAYS returned "{major}.{minor}" release strings. now it does not.
Did it return `{major}.{minor}` even when Debian releases used `X.Y.Z`?
If yes, then it should just return `10` these days as Debian no longer
uses `X.Y.Z`, but only `X.Y` (and `Y` is basically the patch level); or
just `X` to identify releases.
> I use this ALL THE TIME to check status of my systems.
What status? That you have installed all recent updates? But just
checking version numbers doesn't indicate that (it misses both X-updates
and X-security).
> https://www.freedesktop.org/software/systemd/man/os-release.html
> (seems as good a place as any)
>
> specifies: "...This field is optional. Example: "VERSION_ID=17" or
> "VERSION_ID=11.04"..."
>
> clearly it is intended to be able to support {major}.{minor}, and is
> *optional*.
Though version numbers like `11.04` aren't following the {major}.{minor}
scheme. In fact the examples don't include the patch level (I assume
the `11.04` refers to Ubuntu's version scheme), so they suggest we
should just use VERSION_ID=10.
> So, my vote is to put the full "{major}.{minor}" there. anyone parsing it
> can always
> strip past the '.' if they don't care about the minor part, and i'll argue if
> they are
> NOT doing so, then that'd be a bug, as the field certainly can contain '.' by
> the
> above reference.
No, with Ubuntu's version scheme `18.04` and `18.10` are different
releases. But Debian's `10.0` and `10.1` are the same release.
So you cannot just stop the part after the `.` and expect automated
systems to work correctly, but would have to decide on a
per-distribution basis how to treat the `VERSION_ID` if Debian were to
put `10.1` there.
(While for Debian Woody or Sarge VERSION_ID=3.0 or VERSION_ID=3.1 would
have been correct.)
Ansgar
