Select /etc/os-release ID, VARIANT_ID, and ID_LIKE

[bgilbert]

ID=coreos implies Container Linux, so we shouldn't use that. ID=fedora + VARIANT_ID=coreos is defensible, but tools that see ID=fedora might expect things like dnf or /etc/sysconfig/network-scripts to work. ID=fedora-coreos seems harder to justify. Other options may exist.

Ultimately this seems like a broader Fedora policy question, and maybe it should get some attention at that level.

[dustymabe]

cc @mattdm

[dustymabe]

ID=fedora + VARIANT_ID=coreos would be my vote.

[jlebon]

but tools that see ID=fedora might expect things like dnf or /etc/sysconfig/network-scripts to work.

FWIW, Fedora Silverblue/Atomic Host today both have ID=fedora. Tools/scripts usually use /run/ostree-booted to explicitly check if they're running on an OSTree system. Related to this, there were also musings in coreos/rpm-ostree#405 for handling /usr/bin/dnf and e.g. emitting a message or redirecting to rpm-ostree if it's safe.

+1 for ID=fedora and VARIANT_ID=coreos

[cgwalters]

This is going to be a super bikeshed discussion without a bit more data. I think "tools that see ID=fedora" is a very valid concern. However, I think a general best practice is to use feature detection and not OS detection. For example, people should be using if test -x /usr/bin/dnf, not looking for fedora in /usr/lib/os-release - among other reasons, doing the latter totally breaks with derivatives in play. (Yes, there's ID_LIKE but still)

So it'd be interesting to see if we can think of any concrete examples of tools that actually look for ID=fedora (or ID_LIKE=fedora !)

To turn this whole discussion around - what would break if we did ID=$(uuidgen) for each new build? What tools are really looking at that field today?

[mscherer]

While feature detection is surely more robust, that's also much more complex to handle in various tools that do look at that. For example, ansible do have package manager detection, but on atomic, that's a mess since there is several package manager (atomic, docker, rpm-ostree and flatpak, for silverblue).

Having a ID permit at least to make high level choice. I think the ID should be considered as part of a API, and it should mean something (like, when you see that, and that version, then you can expect this). No one benefit from having complex detection logic duplicated in each and every tools that could have to deduce something based on the name.

[cgwalters]

While feature detection is surely more robust, that's also much more complex to handle in various tools that do look at that. For example, ansible do have package manager detection,

Note that one can also use flatpak on e.g. classic Fedora - not to mention Ubuntu, etc. So such ID-based detection is already broken.

[dustymabe]

currently this is implemented as ID=fedora + VARIANT_ID=coreos in the fedora-coreos-release rpm:

[core@coreos ~]$ cat /etc/os-release | grep -Pi '(variant|ID)'
ID=fedora
VERSION_ID=29
PLATFORM_ID="platform:f29"
VARIANT="CoreOS"
VARIANT_ID=coreos

PR to update the design doc: #46

[dustymabe]

closed in #46