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
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.
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
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.