[Suggestion] Use `/etc/os-release` or `/etc/lsb_release` for distrobox-upgrade #1899

uncomfyhalomacro · 2023-05-09T07:04:01Z

uncomfyhalomacro
May 9, 2023

Detecting which package manager is available through command can be faulty. For example, I have osc installed in my system before and tried out distrobox - osc also pulls dnf as part of the recommends (?). And because of that this may have mess up my distrobox install causing it to look for dnf even after I removed it - related issue #706 .

Wouldn't it be better to use /etc/os-release or /etc/lsb_release to check which distro someone has at first and use the default package manager then use command as a fallback later?

Errata: osc does not have dnf installed as part of recommends. But I do believe it might be some obs-service-* package that has dnf as part of its recommends since I used to run osc on the host with those plugins.

PS: This could be a good discussion to look out for. Not a high priority to be honest since all of us are busy with our lives at this moment.

CC: @luc14n0 @89luca89

89luca89 · 2023-06-10T08:38:51Z

89luca89
Jun 10, 2023
Maintainer

Thanks @uncomfyhalomacro
This is indeed a possible improvement, it has been brought up before, but hadn't the time/will to look into it

Open to suggestions :)

0 replies

luc14n0 · 2023-06-11T19:26:45Z

luc14n0
Jun 11, 2023

This should be quite straightforward to be done. We can source the file with . /etc/os-release, then we have access to the variables declared there. ID seems like a nice prospect because its short and lower case. ID_LIKE looks interesting too, for example if all Debian based distros define it as debian - like Ubuntu does -, that would make our lives easier.

Then we can use case to choose the right package manager:

case "${ID_LIKE}" in
    debian) package_manager=apt ;;
    ...
esac

The tough part is researching /etc/os-release of the countless distros around, perhaps the community is willing to give a hand with that.

If no one takes a stab at this, in my next round of distrobox contributions I could add this task to my Todo list.

0 replies

89luca89 · 2023-06-11T21:57:03Z

89luca89
Jun 11, 2023
Maintainer

Yea the fact that we can simply source it is really nice

We need more info about which thing we can use to just infere the pkg manager
Latest batch of commits to init now allows for more flexibility in packages, they are checked before installed, this allows to declare a dependency that is called differently between 2 OSes with the same package manager (see maybe ubuntu 23 vs debian 8)

The only thing that we might lose (i'm just guessing) is the ability to "just try and see if it works"
Like now you just have to have a supported pkg manager
With this other approach you need a supported distribution name, which is not a given sometimes

0 replies

89luca89 · 2023-06-12T08:56:01Z

89luca89
Jun 12, 2023
Maintainer

Here is a list of all the os-release in all the different distros in the compatibility list

0 replies

luc14n0 · 2023-06-13T05:39:57Z

luc14n0
Jun 13, 2023

Yeah, we need to have a closer looking to see if there's really a pattern we can rely on rather than going with distroA|distroD|distroH|distroL|distroO) if command -v foo; then package_manager=foo; fi.

The only thing that we might lose (i'm just guessing) is the ability to "just try and see if it works"
Like now you just have to have a supported pkg manager
With this other approach you need a supported distribution name, which is not a given sometimes

Yeah, I see the lines of code increasing a bit with this proposed approach. The "try and see" approach should work most of the time, because most of the time distros only have package manager. And if there's only one package, most likely there's only one canonical way of updating the system.

However, there could be corner cases where things could end up not so pretty, with the current approach. The more people use distrobox the more likely such a thing could happen.

0 replies

89luca89 · 2023-06-13T07:36:56Z

89luca89
Jun 13, 2023
Maintainer

Yeah, we need to have a closer looking to see if there's really a pattern we can rely on rather than going with distroA|distroD|distroH|distroL|distroO) if command -v foo; then package_manager=foo; fi.

Yea that's what I fear :/ (and definitely won't do)

And if there's only one package, most likely there's only one canonical way of updating the system.

However, there could be corner cases where things could end up not so pretty, with the current approach. The more people use distrobox the more likely such a thing could happen.

This in fact can be a problem if/when openSUSE migrates to dnf
but maybe doing a mixed approach can be useful like:

if command -v package_manager; then
    > we get from os-release the distro
    > package_manager install list of packages for detected distro
    > else we install the package list for the most associated distro (dnf-fedora/rh, apt-debian etc etc)

so we just add a little logic to the present approach this way

0 replies

luc14n0 · 2023-06-15T14:22:40Z

luc14n0
Jun 15, 2023

To be honest, I don't see openSUSE switching to DNF as its default package manager.

However, I had the same thought about some cases needing a mixed approach. I'm gonna think this over when I get some time to spare.

0 replies

89luca89 · 2023-06-15T16:41:57Z

89luca89
Jun 15, 2023
Maintainer

Thanks for the help!

0 replies

marcosps · 2024-01-12T13:04:54Z

marcosps
Jan 12, 2024

To be honest, I don't see openSUSE switching to DNF as its default package manager.

However, I had the same thought about some cases needing a mixed approach. I'm gonna think this over when I get some time to spare.

Hey @luc14n0, did you manage to think about the issue?

0 replies

doccaz · 2024-01-12T14:59:20Z

doccaz
Jan 12, 2024

I made a script to evaluate what fields can be used based on these samples.
My experience with enterprise distros would suggest using CPE, which is guaranteed to be unique. However, I see that quite a few (40 out of 84 to be exact) do not have that field.

Also:

34 do not have ID_LIKE
9 do not have ID
9 do not have VERSION (what?)
9 do not have VERSION_ID
all of them have NAME and PRETTY_NAME

So, my proposal would be to use NAME to simplify things.

get_distros.sh.txt
summary.txt

0 replies

doccaz · 2024-01-12T15:08:25Z

doccaz
Jan 12, 2024

Further analyzing, we have 25 unique NAME tags:

erico@suselab-erico:~/Projetos/distrobox> egrep "NAME" summary.txt | sort  | uniq
--> NAME=[AlmaLinux]
--> NAME=[Alpine Linux]
--> NAME=[Amazon Linux]
--> NAME=[Amazon Linux AMI]
--> NAME=[Arch Linux]
--> NAME=[CentOS Linux]
--> NAME=[CentOS Stream]
--> NAME=[Clear Linux OS]
--> NAME=[Crystal Linux]
--> NAME=[Debian GNU/Linux]
--> NAME=[Deepin]
--> NAME=[Fedora Linux]
--> NAME=[Gentoo]
--> NAME=[Kali GNU/Linux]
--> NAME=[Mageia]
--> NAME=[openSUSE Leap]
--> NAME=[openSUSE Tumbleweed]
--> NAME=[Oracle Linux Server]
--> NAME=[Red Hat Enterprise Linux]
--> NAME=[Rocky Linux]
--> NAME=[Scientific Linux]
--> NAME=[Slackware]
--> NAME=[Ubuntu]
--> NAME=[Void]
--> NAME=[Wolfi]

So, I guess we'd only need a "case" for these items only to define the corresponding package manager.

0 replies

doccaz · 2024-01-12T15:21:07Z

doccaz
Jan 12, 2024

So, it would boil down to something like this:

#!/bin/bash
DISTRO_NAME=$(egrep "^NAME=.*" ${1}| cut -d\= -f2-)

if [[ ${DISTRO_NAME} =~ "Ubuntu" ]] || [[ ${DISTRO_NAME} =~ "Debian" ]]; then
        echo "we should use apt-get!"
elif [[ ${DISTRO_NAME} =~ "Red Hat" ]] || [[ ${DISTRO_NAME} =~ "Oracle Linux" ]] || [[ ${DISTRO_NAME} =~ "CentOS" ]] || [[ ${DISTRO_NAME} =~ "AlmaLinux" ]]; then
        echo "we should use dnf!"
elif [[ ${DISTRO_NAME} =~ "Arch" ]]; then
        echo "we should use pacman!"
elif [[ ${DISTRO_NAME} =~ "SUSE" ]]; then
        echo "we should use zypper!"
else 
        echo "I don't know! ¯\_(ツ)_/¯ "
fi

Testing:

erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-archlinux-latest.txt 
we should use pacman!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-almalinux-9-minimal.txt 
we should use dnf!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-centos-7.txt 
we should use dnf!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-debian-stable.txt 
we should use apt-get!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-ubuntu-14-04.txt 
we should use apt-get!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-opensuse-toolbox-latest.txt 
we should use zypper!
erico@suselab-erico:~/Projetos/distrobox> ./guess_packager.sh samples/os-release-wolfi-base-latest.txt 
I don't know! ¯\_(ツ)_/¯

0 replies

doccaz · 2024-01-12T15:23:51Z

doccaz
Jan 12, 2024

And of course, if there are exceptions, like suppose there 4 versions of CentOS and one of them doesn't support DNF... test the other fields, preferrably PRETTY_NAME and then VERSION, if it exists.

0 replies

marcosps · 2024-01-17T15:37:49Z

marcosps
Jan 17, 2024

Checkihg the distrobox-upgrade script, where the checks if a package manager is installed, we could just call a function, like the one that @doccaz did, and then compare which package returned, instead of checking which package manager is installed. What do you think @89luca89 ?

0 replies

uncomfyhalomacro · 2024-01-18T05:40:09Z

uncomfyhalomacro
Jan 18, 2024
Author

Yeah my suggestion seems flaky after I read all suggestions here, especially from @doccaz

0 replies

89luca89 · 2024-02-01T22:21:21Z

89luca89
Feb 1, 2024
Maintainer

Thanks for thinking about this!

Only problem I see is supporting unknown distros

For example, wolfi vs alpine, both use apk but different /etc/os-release

The proposed solution would make it "hardcoded" which family of distros we support,
Not that this is wrong, but it's a paradigm shift that should be thought about

0 replies

doccaz · 2024-02-01T22:50:09Z

doccaz
Feb 1, 2024

Thanks for thinking about this!

Only problem I see is supporting unknown distros

For example, wolfi vs alpine, both use apk but different /etc/os-release

The proposed solution would make it "hardcoded" which family of distros we support, Not that this is wrong, but it's a paradigm shift that should be thought about

In this case, you could resort to the other available fields, like PRETTY_NAME or VERSION, as I mentioned.

0 replies

89luca89 · 2024-02-01T22:55:33Z

89luca89
Feb 1, 2024
Maintainer

Thanks for thinking about this!
Only problem I see is supporting unknown distros
For example, wolfi vs alpine, both use apk but different /etc/os-release
The proposed solution would make it "hardcoded" which family of distros we support, Not that this is wrong, but it's a paradigm shift that should be thought about

In this case, you could resort to the other available fields, like PRETTY_NAME or VERSION, as I mentioned.

That doesn't always work

Another thing would maybe do a pkg manager detection fallback

1 - ID
2 - NAME
3 - PRETTY_NAME
4 - we fallback to pkg manager detection like now

0 replies

doccaz · 2024-02-01T22:59:30Z

doccaz
Feb 1, 2024

That doesn't always work

Another thing would maybe do a pkg manager detection fallback

1 - ID 2 - NAME 3 - PRETTY_NAME 4 - we fallback to pkg manager detection like now

Exactly. If everything else fails, test for the package manager binaries.

0 replies

sandorex · 2024-02-19T18:39:00Z

sandorex
Feb 19, 2024

Im late to the discussion but this may be worth doing until proper solution is in place?
Basically order package managers by niche-ness(?)

For example on openSUSE, if zypper is checked first then it will not look for dnf so quick order i thought of
This still cannot deal with idk installing pacman on ubuntu but does it really have to handle that?

swupd
xbps-install
apk
emerge
slackpkg
pacman
zypper # must be before dnf because openSUSE
dnf
microdnf # dnf should probably be preferred
yum # must be after dnf
apt-get

Looking forward to your thoughts

0 replies

89luca89 · 2024-02-19T19:15:45Z

89luca89
Feb 19, 2024
Maintainer

mmh this would be a little stopgap, but that would do some damage on an opensuse with both dnf and zypper installed (I guess?? I do not know if installing dnf removes zypper and vice versa 🤷‍♂️ )

0 replies

marcosps · 2024-02-19T19:29:53Z

marcosps
Feb 19, 2024

I believe that we can have both, as there are some packages that install dnf, IIRC. But either way, for such a tool like distrobox, I believe that preferring zypper is safe. I never saw anyone using dnf on openSUSE as by default zypper is the package manager.

0 replies

sandorex · 2024-02-19T20:36:32Z

sandorex
Feb 19, 2024

According to opensuse wiki dnf is in the repos but also it is never mentioned that it is unsupported only thing i could find is the following

Specific functionality that is enabled by default with zypper can not be reproduced using DNF without the additional installation of plugins. Functionality such as "protected" packages and snapper integration require the use of plugins.

I do not know if installing dnf removes zypper and vice versa 🤷‍♂️

No, dnf is available to install but zypper is kept, i do not know if zypper can be uninstalled but would that really be something distrobox need to care about if zypper works and is the default?

EDIT: Also on archlinux you can install apt and dnf but i do not think we should care for such cases

0 replies

marcosps · 2024-02-20T14:59:11Z

marcosps
Feb 20, 2024

IMHO, distrobox should first respect the default package manager for a distro. After this is done, well, some corner cases could be handled. (And yes, I understand that's kind of messed up to have two package managers, but what do I know?).

0 replies

[Suggestion] Use /etc/os-release or /etc/lsb_release for distrobox-upgrade #1899

Uh oh!

Uh oh!

Replies: 24 comments

Uh oh!

89luca89 Jun 10, 2023 Maintainer

Uh oh!

Uh oh!

89luca89 Jun 11, 2023 Maintainer

Uh oh!

89luca89 Jun 12, 2023 Maintainer

Uh oh!

Uh oh!

89luca89 Jun 13, 2023 Maintainer

Uh oh!

Uh oh!

89luca89 Jun 15, 2023 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

uncomfyhalomacro Jan 18, 2024 Author

Uh oh!

89luca89 Feb 1, 2024 Maintainer

Uh oh!

Uh oh!

89luca89 Feb 1, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

89luca89 Feb 19, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

[Suggestion] Use `/etc/os-release` or `/etc/lsb_release` for distrobox-upgrade #1899

89luca89
Jun 10, 2023
Maintainer

89luca89
Jun 11, 2023
Maintainer

89luca89
Jun 12, 2023
Maintainer

89luca89
Jun 13, 2023
Maintainer

89luca89
Jun 15, 2023
Maintainer

uncomfyhalomacro
Jan 18, 2024
Author

89luca89
Feb 1, 2024
Maintainer

89luca89
Feb 1, 2024
Maintainer

89luca89
Feb 19, 2024
Maintainer