Skip to main content ↑ ↓
Topic: [RESOLVED] ID_LIKE Missing From /etc/os-release (Read 561 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[RESOLVED] ID_LIKE Missing From /etc/os-release

Hello everyone,

Wanted to point out that in the /etc/os-release file (https://gitea.artixlinux.org/packages/filesystem/src/branch/master/os-release), a line for ID_LIKE="arch" is missing.

Why is this important?  The install script for Liquorix Kernel uses the ID and ID_LIKE values to determine the true underlying OS so the correct install procedure and distribution branch (if needed), is selected when the repository is added.

Since Artix is based directly on top of Arch, including ID_LIKE="arch" will simplify any tools that use /etc/os-release to identify and grok the underlying operating system.

Here's the issue that prompted me to post here: https://techpatterns.com/forums/about3041.html

And here's the official documentation for how os-release is supposed to be used: https://www.freedesktop.org/software/systemd/man/os-release.html.  An important quote as well regarding ID_LIKE:

Quote
A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from.

...

Examples: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate. For an operating system with "ID=ubuntu", an assignment of "ID_LIKE=debian" is appropriate.

EDIT: Install script was modified to look for evidence that the system is actually an Arch base.

Re: ID_LIKE Missing From /etc/os-release

Reply #1 –
While not questioning the validity of your request, in the meanwhile with the current situation, so far as the liquorix kernel goes, apparently the linux-zen kernel in the repos is a good equivalent because that's what liquorix is based on:
https://wiki.archlinux.org/title/kernel

Re: ID_LIKE Missing From /etc/os-release

Reply #2 –
Just playing devils advocate :)

If you read through the thread of the the forum link you posted the admin of whatever site that is doesn't seem particularly enamoured with the implementation of ID_LIKE
Quote
ID_LIKE is totally random, and can't be relied on at all.

Sometimes it's right, or correct, and other times it's just nonsensical.

The fault in this case lies with redhat, and Poettering, who was tasked with creating the os-release 'standard', but because it was redhat, which has almost no derived distros to speak of beyond the clones, they didn't make that robust enough to handle complex derived scenarios, like lubuntu 22-4 derived from ubuntu 22-4 derived from debian sid 2021-09.
The lack of it has never caused a problem for me AFAIK. I've only just learnt that it's a 'thing'.

If the install script for Liquorix Kernel needs it then it maybe necessary in that case (manually adding it would not take long, would need repeating if 'filesystem' get an update I guess ?) but also there's the possibility another script or program could, as part of it's logic, find 'Arch' in ID_LIKE and then make the assumption that the system has systemd and proceed accordingly.

Just seeing Freedesktop (an oxymoron imho) and systemd in the link to the specs is enough to irrationally make the hairs on the back of my neck stand up.

Re: ID_LIKE Missing From /etc/os-release

Reply #4 –
Quote
If you read through the thread of the the forum link you posted the admin of whatever site that is doesn't seem particularly enamoured with the implementation of ID_LIKE

Yep, techAdmin is the author of inxi.  He uses heuristics to determine what the operating system is rather than what is provided because of issues like this.  And also the nature of the tool, it's meant to grok the system and interpret what it finds through landmark files and their content rather than trust what the OS tells it at face value.

Going back to the os-release file, in a vacuum the contents tell me that Artix is a distribution similar to Slackware, Debian, OpenSuse.  It is a root distribution that others may make further spins of.  But that's not true, it's derivative of Arch.

Doing some more research, I did notice that ID_LIKE is an addition to the man page in the systemd owned variation of os-release.  On non-systemd man pages for the os-release file/package, it's not there.  For example: https://www.linux.org/docs/man5/os-release.html

With that in mind, I understand if you guys don't want to add it due to its systemd roots.  I can just add some dumb logic like, if pacman exists, append "arch" to the list of possible distributions the underlying system may be from.  Same for apt-get, add "debian", and so forth.

Re: ID_LIKE Missing From /etc/os-release

Reply #5 –
For some closure, the install script was amended with the logic I mentioned earlier:
Code: [Select]
# Append upstream distributions through package manager landmarks
command -v apt-get &> /dev/null && dists="$dists debian"
command -v pacman  &> /dev/null && dists="$dists arch"

I'm sure more exceptions will keep coming up but this should handle most of them.

Quote from: artoo – on
https://github.com/damentz/liquorix-package/blob/6.4/master/scripts/install-liquorix.sh#L91

Code: [Select]
*arch*|*artix*)

 :P

While that does solve the problem immediately, it also sets the precedence that the OS pattern can get out of control.  For example:
Code: [Select]
*arch*|*artix*|*endeavour*|*reborn*|*bespokedistro*|*etc*)

The real pattern here is they're all arch, so I just need to find that out.

Re: [RESOLVED] ID_LIKE Missing From /etc/os-release

Reply #6 –
Anyone can create an AUR account and make a package, btw, if you really wanted to bring the Liquorix kernel to Arch based distros and increase your user base, then a liquorix-bin package in the AUR would make it very easy to install using existing package tools. The advantage of this is that it ties in with the package management system so will fulfill dependency requirements, and get updates along with the system updates if you use an AUR helper, and generally make it much more practical for ordinary users. You could pretty much copy the format from other existing kernel-bin AUR packages.