[RESOLVED] Install script for artix linux (ARCH)
palmekiller
Status: New User - Welcome
Joined: 31 Aug 2023
Posts: 2
Reply Quote
Would really like it if you could fix the installation script to work with artix linux, artix linux is (basicly) arch linux...but without systemd
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1122
Reply Quote
Can you provide the full content of /etc/os-release in a [code] tag please?
Back to top
palmekiller
Status: New User - Welcome
Joined: 31 Aug 2023
Posts: 2
Reply Quote
of course mate :)

:: Code ::

NAME="Artix Linux"
PRETTY_NAME="Artix Linux"
ID=artix
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.artixlinux.org/"
DOCUMENTATION_URL="https://wiki.artixlinux.org/"
SUPPORT_URL="https://forum.artixlinux.org/"
BUG_REPORT_URL="https://bugs.artixlinux.org/"
PRIVACY_POLICY_URL="https://terms.artixlinux.org/docs/privacy-policy/"
LOGO=artixlinux-logo
VERSION_ID=20230501
VARIANT=plasma-openrc


Thank you.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1122
Reply Quote
Thanks, I see the issue. Artix needs ID_LIKE="arch" below ID=.

Check this page for information on how to use os-release: www.freedesktop.org/software/systemd/man/os-release.html

I recommend you submit this as a bug to the maintainers, will probably fix many other apps that use os-release to determine how to interact with the underlying system.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply 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.

inxi has to use about 10x too much code to determine distros and system base because of this failure in design and implementation, leading to the dreaded requirement that to correct the issue, we need yet another standard, making for one more in the stack.

The easiest is to look for files that the parent distro always has, and which the children also always have, or contents of a file that is always the parent's, not the child's.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1122
Reply Quote
I completely disagree, it's pretty clear how it should be used.

ID is the unique distribution name and ID_LIKE is effectively what it's based on. The description is pretty clear and all Debian and Ubuntu distributions use it properly.

As for parsing, it matters how you use it. In Liquorix all I care about is what you're real base distro is, the one the majority of packages come from. Then I point whatever sources file at the most compatible distro.

IMO, Artix is an outlier. Even Manjaro having slightly forked packages (effectively snapshots of Arch), sets ID_LIKE properly. Considering Artix is less popular (but more similar to Arch), they need to fix their os-release file. It's only obvious now that there's a problem, but with less users that's pretty standard.

Also a final discrepancy, if you read the install script, I actually don't care what the real distribution is, I'm just determining the underlying operating system through a process of elimination, going from most specific variation (Ubuntu for example), to Debian. Or another way of saying it, a Debian distro would never say they're compatible with Ubuntu, but an Ubuntu distro will say they have Debian roots.

There's not that many root distros, so figuring this out is rather simple. But yes, if my aim was to determine what exactly the OS was, this wouldn't be sufficient.

< Edited by damentz :: Sep 2, 23, 10:54 >

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
heh, how it _should_ be used is quite different from how it _is_ used. Which is unfortunate.

But it's because the spec did not cover enough variations, for example, you might see an ID_LIKE=mint for a respin of mint, there's really no telling what you will find.

But the best strategy is to test for features, unfortunately because rpm can be installed on other package managed systems, a simple package manager installed test is not adequate, but for your needs, this really does not matter.

Arch is the easiest to detect as a rule, and its derived distros. It gets shakier from there.

I basically just gave up, and now inxi --recommends doesn't even try to guess, it just detects the installed package managers, and shows the data for all of them it can find, same goes for the package count feature, though if there's a count of 0, I think it does assume it's not active.

Basically only the simple cases fit into the spec, and because the complex cases are simply not handled at all by os-release, distro builders tend to just make up how to use the fields, basically it depends mostly on how they think of it as far as I can tell.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1122
Reply Quote
palmekiller, latest install script should solve your problem. I added some basic dumb logic to throw in possible root distributions through the package manager.

You can read the commit if you're interested: github.com/damentz/liquorix-package/commit/e76c92587e0d5a313258c11bb3353efc08c2c7ad

EDIT: Marking thread as resolved.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours