Bug#944351: Providing minor version somewhere in /etc/os-release in buster
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
Re: Bug#944351: Providing minor version somewhere in /etc/os-release in buster
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
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Thu, Nov 14, 2019 at 08:15:36PM +0100, Santiago Vila wrote: > On Thu, Nov 14, 2019 at 07:10:08PM +0100, Julien Cristau wrote: > > On Fri, Nov 08, 2019 at 01:17:20PM +0100, Santiago Vila wrote: > > > I received this bug from one of the ansible upstream authors: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > > > > > asking to include information about minor version somewhere in > > > /etc/os-release. > > > > > What I'm missing from that bug is the actual use case. The minor > > version seems to me to be pretty meaningless. What problem does > > including it actually fix? > > I would call it marginally useful, but not meaningless. > Fair. > If it was really meaningless, we would not be providing such info in > /etc/debian_version to begin with. > > In this case we would be allowing ansible maintainers for a cleaner > implementation of something which they have already decided to > implement because some users consider it useful. > > As far as we don't break any standard, does a feature need to be > useful for everybody to be implemented, or does it suffice that some > people consider it useful? (for whatever reason). > 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). Cheers, Julien
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Thu, Nov 14, 2019 at 07:10:08PM +0100, Julien Cristau wrote: > On Fri, Nov 08, 2019 at 01:17:20PM +0100, Santiago Vila wrote: > > I received this bug from one of the ansible upstream authors: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > > > asking to include information about minor version somewhere in > > /etc/os-release. > > > What I'm missing from that bug is the actual use case. The minor > version seems to me to be pretty meaningless. What problem does > including it actually fix? I would call it marginally useful, but not meaningless. If it was really meaningless, we would not be providing such info in /etc/debian_version to begin with. In this case we would be allowing ansible maintainers for a cleaner implementation of something which they have already decided to implement because some users consider it useful. As far as we don't break any standard, does a feature need to be useful for everybody to be implemented, or does it suffice that some people consider it useful? (for whatever reason). Should I ask your question to Sam Doran in the referenced bug? In my opinion, /etc/debian_version is deprecated in favour of /etc/os-release. Not losing information (no matter how useful such information might be) in the switch seems a reasonable goal to me. Thanks.
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Fri, Nov 08, 2019 at 01:17:20PM +0100, Santiago Vila wrote: > I received this bug from one of the ansible upstream authors: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > asking to include information about minor version somewhere in > /etc/os-release. > What I'm missing from that bug is the actual use case. The minor version seems to me to be pretty meaningless. What problem does including it actually fix? Cheers, Julien
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Hi Santiago,
On Tue, Nov 12, 2019 at 01:29:38AM +0100, Santiago Vila wrote:
> So, to summarize: I believe putting minor version in VERSION_ID would
> be useful, and I also think that we could do this in buster as far as
> we do it "soon" in the stable cycle, i.e 10.x where x is still small
> (for example, 10.3).
this ('soon in the stable cycle') convinced me, plus this:
> I am of course aware that some setups might break because of this but
> on the other side we can reasonably hope that whatever breakage
> (in hand-made scripts, for example) should be easy to fix.
so I'd now also say: go ahead.
> > I wondering if change should have wider exposure. I suspect not only
> > ansible users will be affected. I'd say this warrants a mail to d-d-a or
> > at least -devel.
> Hmm, what kind of exposure do you have in mind and for what purpose?
mailing d-devel or d-d-a, to get more feedback. but (see above) you
already convinced me that this is not needed. Thanks!
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc
Description: PGP signature
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
tags 944351 - moreinfo
thanks
Note: I have finally the ok from both lsb-release and ansible people.
To answer the question: Yes, the change would be limited to VERSION_ID only.
That would be enough for the minor version to be shown by
"lsb_release -r" or "lsb_release -a", and also enough for ansible
people to implement {{ ansible_distribution_minor_version }}
without having to use ugly hacks.
So, to summarize: I believe putting minor version in VERSION_ID would
be useful, and I also think that we could do this in buster as far as
we do it "soon" in the stable cycle, i.e 10.x where x is still small
(for example, 10.3).
I am of course aware that some setups might break because of this but
on the other side we can reasonably hope that whatever breakage
(in hand-made scripts, for example) should be easy to fix.
(In fact, this change in base-files would fix a not-yet-fixed breakage
in lsb-release).
On Sun, Nov 10, 2019 at 01:14:12PM +, Holger Levsen wrote:
> On Sun, Nov 10, 2019 at 01:24:42PM +0100, Santiago Vila wrote:
> > Ok, I have just uploaded base-files as usual, but if possible I'd like
> > this to be sorted-out for 10.3 (in particular, I still would like to
> > hear from the ansible maintainers).
>
> I wondering if change should have wider exposure. I suspect not only
> ansible users will be affected. I'd say this warrants a mail to d-d-a or
> at least -devel.
Hmm, what kind of exposure do you have in mind and for what purpose?
(I can think of two different purposes, not all of them desirable,
but would like to know yours first :-)
Thanks.
Processed: Re: Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Processing commands for cont...@bugs.debian.org: > tags 944351 - moreinfo Bug #944351 [release.debian.org] Providing minor version somewhere in /etc/os-release in buster Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 944351: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944351 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sun, Nov 10, 2019 at 01:24:42PM +0100, Santiago Vila wrote: > Ok, I have just uploaded base-files as usual, but if possible I'd like > this to be sorted-out for 10.3 (in particular, I still would like to > hear from the ansible maintainers). I wondering if change should have wider exposure. I suspect not only ansible users will be affected. I'd say this warrants a mail to d-d-a or at least -devel. Thanks for maintaining base-files, Santiago! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sat, Nov 09, 2019 at 03:33:26PM +, Adam D. Barratt wrote: > On Sat, 2019-11-09 at 16:09 +0100, Santiago Vila wrote: > > (If we can't sort this out for 10.2 I'll have to upload base-files > > for 10.2 as usual. What's the real deadline for that? This weekend?) > > Yep. Ok, I have just uploaded base-files as usual, but if possible I'd like this to be sorted-out for 10.3 (in particular, I still would like to hear from the ansible maintainers). (I assume and hope that keeping this bug open until we have all the info should not be a problem). Thanks.
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sat, 2019-11-09 at 16:09 +0100, Santiago Vila wrote:
> So I think we could change VERSION_ID and nothing else and interpret
> Bug #939733 in the sense that the minor version should be in
> /etc/os-release just "somewhere". I also would like to think that
> this should be enough for ansible to implement {{
> ansible_distribution_minor_version }} without being too much hackish.
>
> Cc:ing interested parties again.
>
> (If we can't sort this out for 10.2 I'll have to upload base-files
> for 10.2 as usual. What's the real deadline for that? This weekend?)
Yep.
Regards,
Adam
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sat, Nov 09, 2019 at 02:10:45PM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 2019-11-08 at 13:17 +0100, Santiago Vila wrote:
> > I received this bug from one of the ansible upstream authors:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197
> >
> > asking to include information about minor version somewhere in
> > /etc/os-release.
> >
> > I first said "not yet" because we were very close to the release of
> > buster and the behaviour of /etc/debian_version and /etc/os-release
> > was already "documented" or "announced" in base-files changelog, as
> > usual. My plan was to consider that for bullseye.
> >
> > However, there is a glitch in lsb-release:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939733
> >
> > We could revert the change in lsb-release so that it looks at
> > /etc/debian_version again, but we could also do the change
> > in base-files now and fix this glitch in the most standard way.
> >
> > So: Would you approve that base-files 10.3+deb10u2 for Debian 10.2
> > has VERSION_ID="10.2" in /etc/os-release (and 10.x from now on)
> > instead of "10"?
>
> To confirm, is the proposal to end up with:
>
> PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> NAME="Debian GNU/Linux"
> VERSION_ID="10.2"
> VERSION="10 (buster)"
>
> ?
That's what I would like to be but unfortunately, I'm not 100% sure.
I'm awaiting for reply from the ansible maintainer who contacted me
and also from the LSB maintainers.
The complain in Bug #939733 is that "lsb_release -d" does not show the
point release (and that would not be "fixed" by updating VERSION_ID),
but according to Simon McVittie in Bug#914287.
lsb_release -d
os-release PRETTY_NAME looks suitable for this. It can include the
OS vendor, version number and/or codename. One difference is that
stretch has PRETTY_NAME="Debian GNU/Linux 9 (stretch)", without
the 9.6; but I don't think that's a very important distinction, so
it might make most sense for $(lsb_release -ds) in the buster
release to be "Debian GNU/Linux 10 (buster)" across all point
releases.
So I think we could change VERSION_ID and nothing else and interpret
Bug #939733 in the sense that the minor version should be in
/etc/os-release just "somewhere". I also would like to think that this
should be enough for ansible to implement {{ ansible_distribution_minor_version
}}
without being too much hackish.
Cc:ing interested parties again.
(If we can't sort this out for 10.2 I'll have to upload base-files for
10.2 as usual. What's the real deadline for that? This weekend?)
Thanks.
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Control: tags -1 + moreinfo On Fri, 2019-11-08 at 13:17 +0100, Santiago Vila wrote: > I received this bug from one of the ansible upstream authors: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197 > > asking to include information about minor version somewhere in > /etc/os-release. > > I first said "not yet" because we were very close to the release of > buster and the behaviour of /etc/debian_version and /etc/os-release > was already "documented" or "announced" in base-files changelog, as > usual. My plan was to consider that for bullseye. > > However, there is a glitch in lsb-release: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939733 > > We could revert the change in lsb-release so that it looks at > /etc/debian_version again, but we could also do the change > in base-files now and fix this glitch in the most standard way. > > So: Would you approve that base-files 10.3+deb10u2 for Debian 10.2 > has VERSION_ID="10.2" in /etc/os-release (and 10.x from now on) > instead of "10"? To confirm, is the proposal to end up with: PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10.2" VERSION="10 (buster)" ? Regards, Adam
Processed: Re: Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Processing control commands: > tags -1 + moreinfo Bug #944351 [release.debian.org] Providing minor version somewhere in /etc/os-release in buster Added tag(s) moreinfo. -- 944351: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944351 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Managers:
I received this bug from one of the ansible upstream authors:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197
asking to include information about minor version somewhere in /etc/os-release.
I first said "not yet" because we were very close to the release of buster
and the behaviour of /etc/debian_version and /etc/os-release was
already "documented" or "announced" in base-files changelog, as usual.
My plan was to consider that for bullseye.
However, there is a glitch in lsb-release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939733
We could revert the change in lsb-release so that it looks at
/etc/debian_version again, but we could also do the change
in base-files now and fix this glitch in the most standard way.
So: Would you approve that base-files 10.3+deb10u2 for Debian 10.2 has
VERSION_ID="10.2" in /etc/os-release (and 10.x from now on) instead of
"10"?
My only problem with this is how we would explain the change
after having promised (sort of) that the file would not
change in such way in 10.x.
On the other hand, people who use constructs like
{{ ansible_distribution_major_version }}, which is probably a lot
better than parsing the file by hand, would not be affected at all.
Thanks.
