search

ublue-os / bazzite

Bazzite is a custom image built upon Fedora Atomic Desktops that brings the best of Linux gaming to all of your devices - including your favorite handheld.
https://bazzite.gg
Apache License 2.0
3.35k stars 185 forks source link

Improve distribution identification via os-release file #1249

Closed paidhi closed 1 month ago

paidhi commented 1 month ago

Many automation scripts (installers, deployment, configuration management, etc.) rely on information in the os-release file. They parse fields like: NAME, ID, ID_LIKE, CPE_NAME, VARIANT, VARIANT_ID, VERSION, VERSION_ID, etc. Some also look for the presence of dedicated software packages (e.g. fedora-release-identity-*).

Currently Bazzite has package fedora-release-identity-kinoite installed and the various fields in /etc/os-release report either "fedora" or "kinoite".

The only option I see currently to identify the distribution via this method is to either check for the presence of package ublue-update-*.bazzite-*.noarch or parse field PRETTY_NAME from /etc/os-release (e.g. PRETTY_NAME="Fedora Linux 40.20240621.0 (Bazzite)"). But this doesn't feel very elegant to me.

It would be great if Ublue-based distributions (Aurora/Bluefin/Bazzite) could improve this by identifying itself more clearly in the spirit of the Freedesktop/CPE specifications. Maybe take some pointers from how Nobara Linux does it.

Example for Fedora 39:

NAME="Fedora Linux"
VERSION="39 (Thirty Nine)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39 (Thirty Nine)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f39/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-11-12

Example for Nobara 39 (based on Fedora 39):

NAME="Nobara Linux"
VERSION="39 (KDE Plasma)"
ID=nobara
ID_LIKE="rhel centos fedora"
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Nobara Linux 39 (KDE Plasma)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=nobara-logo-icon
CPE_NAME="cpe:/o:nobaraproject:nobara:39"
DEFAULT_HOSTNAME="nobara"
HOME_URL="https://nobaraproject.org/"
DOCUMENTATION_URL="https://www.nobaraproject.org/"
SUPPORT_URL="https://www.nobaraproject.org/"
BUG_REPORT_URL="https://gitlab.com/gloriouseggroll/nobara-images"
REDHAT_BUGZILLA_PRODUCT="Nobara"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Nobara"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-05-14
VARIANT="KDE Plasma"
VARIANT_ID=kde

On Bazzite it looks like this:

NAME="Fedora Linux"
VERSION="40.20240621.0 (Kinoite)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40.20240621.0 (Bazzite)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://kinoite.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-kinoite/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://pagure.io/fedora-kde/SIG/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Kinoite"
VARIANT_ID=kinoite
OSTREE_VERSION='40.20240621.0'
fiftydinar commented 1 month ago

The reason why Bazzite doesn't modify /etc/os-release file is because scripts which rely on it would fail, in case they would want to do modifications related to Fedora. They would look for fedora ID or similar, which wouldn't be present if modified when applying your suggestion.

paidhi commented 1 month ago

I'm sorry to see this issue is closed so quickly and dismissed as "not planned".

No doubt scripts rely on that information. As it should be. It is IMO just bad practice to solely rely on "ID". That's why "ID_LIKE", "VARIANT", "VARIANT_ID" and the likes are available. It seems to work for Nobara Linux. That's why I included their os-release file as an example.

It also seems to work OK for other derivative distributions. I have checked distributions based on others: CentOS, AlmaLinux, RockyLinux, Ubuntu, VanillaOS, Mint. They all identify themselves uniquely with "ID" but make use of "ID_LIKE" to give a hint about what they are based on. Even Ubuntu proper uses "ID_LIKE=debian".

Identifying as "fedora" in "ID" could even lead to issues with those scripts and Ublue based distributions. Scripts might assume they can perform tasks that won't work as expected (e.g. dnf vs rpm-ostree, grubby, mounts in /var/..., etc.)

My use case is this: To support Linux distribution testing/distro-hopping I am working on automating a lot of setup with PyInfra. To handle Bazzite properly I need to identify it as "Bazzite" and know that it is based on Fedora and is atomic (based on Kinoite). For now I will just have to parse PRETTY_NAME and look for VARIANT="Kinoite".

Maybe you could mark this as a feature request and keep in the backlog instead of not addressing it?

paidhi commented 3 weeks ago

Update: It looks like there was a change around the same time that this issue was created: https://github.com/ublue-os/bazzite/commit/58fc0b253a237df677dca6aa6f15e1d2d4bfcff4 VARIANT_ID is now set to bazzite.

castrojo commented 3 weeks ago

Yeah not sure if related but we changed those up to match the info Fedora needed for the countme service.