Linux distribution detection is unreliable

[Regrau]

Description

It looks like the linux distribution detection is solely relying on the presence of a distro specific package manager like apt, dnf, or zypper. Here is the package installation file.

This approach will and does fail due to the fact that package managers can be installed on every distribution. Take for example this template.

# This example requires Lima v0.7.0 or later
images:
- location: https://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-efi.aarch64.qcow2
  arch: "aarch64"
mounts:
- location: "~"
- location: "/tmp/lima"
  writable: true

This image has both apt and zypper installed. While both package managers work somewhat reliably, feature parity can't be expected between distributions. With the code above it leads to following command being executed on the openSUSE guest.

DEBIAN_FRONTEND=noninteractive sudo apt-get install -y --no-upgrade --no-install-reccomends -q uidmap iptables sshfs fuse3 dbus-user-session

Which fails with the following result

The flag --no-upgrade is not known.

Due to this, dependencies won't get installed and limas startup sequence times out.

I'd like to propose to implement the distribution detection based on the /etc/os-release file. If this is acceptable I'd try my hand at implementing this. If not, I'd be interested in other ways to make distribution detection more reliable.

[afbjorklund]

Arguably this could also be regarded as a "bug" (missing feature) in apt-rpm, and handled within the apt handler ?

I'd like to propose to implement the distribution detection based on the /etc/os-release file.

The problem with hardcoding distributions (like cloud-init does), is that you have to fork it just to add a new distro...

I would prefer if it was still based on features (apt/yum, systemd/openrc) rather than which brand color that it wears.

[afbjorklund]

Distribution detection is interesting in itself, just not sure if it should be the basis for any technical decisions.

• https://github.com/lima-vm/lima/issues/840

[Regrau]

The problem with hardcoding distributions (like cloud-init does), is that you have to fork it just to add a new distro...

I'm not quite sure I get what you mean by that statement. Could you elaborate please?

Detecting based on features is still brittle, since you can't expect the environment to always be the same. Besides that package names can differ between distributions. So even when the image has the right package manager, it might not list the program under the expected, hardcoded, package name. One could implement a hardcoded approach and in case of failure provide a best effort detection based on features.

So in the words of a famous taco commercial, "Why not both?"

[afbjorklund]

The problem with hardcoding distributions (like cloud-init does), is that you have to fork it just to add a new distro...

I'm not quite sure I get what you mean by that statement. Could you elaborate please?

If you have another distribution that uses the same package manager (etc), but goes by a different name.

Then it fails those checks on the name, and still have to add some code to make it use the same workaround.

Anyway, just something that happened when looked for "alpine" - but really meant "not systemd".

---

I think you are right in this case, it needs to check both features of the package installer and the distro repositories.

We already do this with dnf for instance, so it's already there in the same file. And all the lima examples "should" work...

For the particular bug, it sounds something like "if apt-get and not zypper" to avoid using debs ?

[afbjorklund]

If this is acceptable I'd try my hand at implementing this.

I think you can just source the os-release file as-is, and then use those variables like $ID_LIKE.

. /etc/os-release

if command -v apt-get >/dev/null 2>&1 && [ "$ID_LIKE" = "debian" ]; then

[AkihiroSuda]

taco

I don't know the taco commercial, but having both SGTM 🌮