Arch Linux

Additionally we should decide if our ID should in fact be archlinux, it looks like maybe the motivation of including ID_LIKE at all might be somehow in order to be linked to two different os IDs?

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?)

You may also add VERSION_ID with "rolling" value or whatever as it's mandatory for systemd-boot auto-detection.

About ID, I think like Eli, we should move to archlinux, instead of arch.
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.

filesystem-2018.12-1 is in testing.

@seblu: "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

The problem with changing "ID" is that there are existing projects which are relying on it, an example from snapd :

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.

@Jensen: you are right.

@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

@seblu Among things that I can found some rationale for, are:

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.

"A string uniquely identifying the system image used as the origin for a distribution."

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.

It may be also interpreted as system installation image (Arch iso release version). As mentioned above that value doesn't have to be meaningful, it can be set to "systemd is crap" if this pleases everyone.

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

Here's another app which may use VERSION_ID: https://bugs.archlinux.org/task/60991 .

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#60991  is not an attempt to get VERSION_ID in /etc/os-release, don't misinterpret it as such.

@nl6720

I don't. I've referenced it because it contains info which may be useful here.