FS#58499 - [filesystem] /usr/lib/os-release should have empty ID_LIKE
Attached to Project:
Arch Linux
Opened by Erich Eckner (deepthought) - Tuesday, 08 May 2018, 12:46 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 24 April 2019, 23:27 GMT
Opened by Erich Eckner (deepthought) - Tuesday, 08 May 2018, 12:46 GMT
Last edited by Sébastien Luttringer (seblu) - Wednesday, 24 April 2019, 23:27 GMT
|
Details
Description:
From the man page of os-release: "ID_LIKE= [...] It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces [...]" namely, it should not list the os itself, but only other os'es it is related to - none in the case of arch. |
This task depends upon
Closed by Sébastien Luttringer (seblu)
Wednesday, 24 April 2019, 23:27 GMT
Reason for closing: Fixed
Wednesday, 24 April 2019, 23:27 GMT
Reason for closing: Fixed
The current state of things leads to confusion for derivatives like archlinuxarm, archlinux32, parabola, etc. who may list either one or both.
(If I understand the spec, they should list ID_LIKE="arch" to match our ID, but if we ourselves are claiming to be "like archlinux" what do they do?)
So, let's try that.
About ID_LIKE, I agree, as man says:
```
An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible.
```
So, I will remove it.
About VERSION_ID, man says:
```
Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case, VERSION and VERSION_ID may be unset. Applications should not rely on these fields to be set.
```
So, we are correct to not use it.
Documentation says "may be unset" but is it big issue for you to set it? systemd-boot needs either VERSION_ID or BUILD_ID. It would be very nice if you set one of those to any value you like. There is nothing to lose from this and it will make life easier for some people :)
https://wiki.archlinux.org/index.php/systemd-boot#Preparing_kernels_for_/EFI/Linux
https://github.com/systemd/systemd/issues/186
https://github.com/snapcore/snapd/blob/8dae89eaca2e94fd2d9d1dd5323c26dae9eaeaf7/dirs/dirs.go#L204
https://github.com/snapcore/snapd/blob/5ba5d3876d4be7482aa889515b4da7efc72bfd70/cmd/autogen.sh#L29
I think it's better to stay with "ID=arch" for backward compatibility as difference between "arch" and "archlinux" purely cosmetic.
@Jake:
When I read the bug report you mention and the following commit message[1], I understand that BUILD_ID looks more appropriate that VERSION_ID for rolling releases.
But after reading the man page[2], and the commit introducing BUILD_ID[3], I'm not really sure to understand what is the purpose of this field.
What do you think of adding BUILD_ID="rolling"?
[1] https://github.com/systemd/systemd/commit/59658d1958a7990722240e23c25163e98aa013c8
[2] https://www.freedesktop.org/software/systemd/man/os-release.html
[3] https://github.com/systemd/systemd/commit/f0b647223ded79068dd1d92da329d2ea95527590
1. Matching filesystem package version (BUILD_ID=2018.12-2), the downside is that it have to be updated on each filesystem update.
2. Unix epoch (BUILD_ID=1970-01-01), to mimic somewhat reproducible builds approach.
3. Rolling (BUILD_ID=rolling), as it's closest to the truth :)
Anyway any non-empty value will do its job.
But this would imply that we have a version of the system image, which is wrong... :/ It sounds like systemd-boot is flawed, fortunately I use grub with encrypted /boot so I don't care about manually dancing around secure boot verification for my kernel.
Regarding snapd, it is buggy since it needs to check for both arch and archlinux -- some derivatives use one, some use the other, some use both in their ID_LIKE field. I'd be fine with using ID=arch to stick with our current model, but we need to stop advertising ourselves as "like archlinux" in order to reduce the current confusion.
Actually I can only speak for a handful of distros, but:
Antergos (the first distro I looked at and saw being confused) used to use "archlinux", but accepted my PR from September to use "arch": https://github.com/Antergos/antergos-alpm-hooks/pull/5 Despite this, they haven't actually released a new version of their hooks package, so...
Manjaro used to not use anything, now they do use "arch".
Parabola and archlinux32 use both.
archlinuxarm uses "arch" exclusively.
Given there's a number of places using "arch" and the holdouts are moving to use it, I guess we should stick with this but drop ID_LIKE.
"Regarding snapd, it is buggy since it needs to check for both arch and archlinux -- some derivatives use one, some use the other, some use both in their ID_LIKE field."
I think they don't care about derivatives right now and perhaps we shouldn't too.
Interestingly it uses 'lsb_release -r' as a fallback which specifies 'DISTRIB_RELEASE=rolling'.
Setting VERSION_ID or BUILD_ID to 'rolling' will give us consistency here.
FS#60991is not an attempt to get VERSION_ID in /etc/os-release, don't misinterpret it as such.I don't. I've referenced it because it contains info which may be useful here.