Re: Bug#944351: Providing minor version somewhere in /etc/os-release in buster

[Stephen Dowdy <sdowdy@ucar.edu>]

On 11/16/19 1:35 AM, Julien Cristau wrote:
> I think if we're talking about changing things in stable the bar has to
> be higher than "someone asked for it", especially when it may break
> things for somebody else (which this very much can).


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.

I use this ALL THE TIME to check status of my systems.  I do not want to have to go
back to a series of conditional tests like:
   if [ -r /etc/redhat-release ]; then
     ...(random parser for redhat formatted release files)...
   elif [ -r /etc/debian-version ]; then
     ...
   elif [ -r /etc/magical-linux-from-mars ]; then
     ...
   fi

I don't know the canonical reference for how /etc/os-release should work, but:

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*.
I don't know that 'lsb_release -rs" is ever allowed to be "optional", so the fact
that lsb_release now defers to /etc/os-release seems like a bug to me.

I don't care how this gets fixed, but it is (to me) a clear bug that breaks historical
functionality.  i have a hard time believing there could be as many people who believe it's
A-OK to only know the major OS version than those who have historically trusted they'd
get the minor release as well.
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.

thanks,
--stephen