Testing for package managers is getting to be a big mess

[jadeallenx]

Proposed strategy: an associative array (i.e., a map in erlang terms, or a dict in python terms) of a command string with a label - execute the command and if it returns "true" then add the label to an output array. When we get the output array back we can see how many elements are in it and then call the appropriate testing functions (if any) for installed packages,

[jadeallenx]

declare -A pkg_system
pkg_system["label"] = "rpm"
pkg_system["probe"] = "command -v rpm"
pkg_system["label"] = "deb"
pkg_system["probe"] = "command -v deb"
pkg_system["label"] = "arch"
pkg_system["probe"] = "command -v pacman"

Then we'd see which of these labels applies and have another list of package names that are distro dependent or something like that? I'm open to other approaches. Probing /etc/os-release is a good suggestion tbh - at least for freedesktop compliant linuxes.

[jadeallenx]

I also think maybe we should have a KERL_CHECK_BUILD_PACKAGES=no (or false, or 0) thing that disables the build package checking. Maybe we could have a simple probe of /etc/os-release and if we recognize it, we'll check some things, and if not, we will emit a message that says "Unknown Linux flavor; not checking build packages. If you want to support this Linux flavor, submit a PR"

[jadeallenx]

It occurs to me if we probe /etc/os-release we could map the ID_LIKE values into an associative array, or if not an associative array (because bash is too old on macOS) maybe into a case statement like this

attempt_probe_os_release() {
  # DO SOME MAGIC HERE
   ::
}

os_release_id = $(attempt_probe_os_release)

case $os_release_id in
  "debian") ...
    _KERL_PROBE_COMMAND=$( dpkg ... )
    _KERL_BUILD_PREREQS="foo bar baz" 
    ;;
  "redhat")
   ...
   ;;
  *) 
   echo "This linux flavor ${os_release_id} is unrecognized. Build prerequisites will not be checked. Support this Linux variant by submitting a PR to https://github.com/kerl/kerl"
   _KERL_CHECK_BUILD_PACKAGES=false
 esac

[paulo-ferraz-oliveira]

Support this Linux variant by submitting a PR to https://github.com/kerl/kerl

My favorite bit 😄

[skwerlman]

in addition to ID_LIKE, you should also be looking at ID, since it will always be present while ID_LIKE is optional. For example, ID_LIKE is missing in Debian and Fedora.

if its helpful, here's a table mapping ID and ID_LIKE to package managers, based in part on this gist, as well as whatever random distros i had access to:

Package Manager	Distro IDs	ID_LIKE
pacman	arch
yum, dnf	amzn, centos	rhel, fedora
yum, dnf	fedora
yum, dnf	almalinux	rhel, fedora, centos
yum, dnf	rhel	fedora
yum, dnf	mageia	mandriva, fedora
yum, dnf	ol
apt, apt-get, dpkg	debian
apt, apt-get, dpkg	ubuntu, kali, raspbian	debian
zypper	opensuse	suse
zypper	sles
pkgtools, slackpkg	slackware
apk	alpine

In the rows where more than one distro ID is listed, the other columns apply exactly to those IDs. Where ID_LIKE is missing, it is not included in that distro's os-release. "ol" is the somewhat cryptic ID for Oracle Linux, which is (afaict) similar to RHEL.

[jadeallenx]

Thanks for the table @skwerlman that's super helpful

[jadeallenx]

Something else that's come up a bunch is that package names using dnf/rpm are not consistent across distros - I know SuSE has some different library names from Fedora or Amazon Linux. So I guess we'll have to account for that somehow too.

[paulo-ferraz-oliveira]

@jadeallenx, if that's Ok with you, I could edit (and keep editing) the initial description to include a simple algo. for the code update when someone eventually gets to this. Otherwise reading through all these comments can contain contradictory suggestions/options (they're good for history, otherwise, but maybe not be "best" place to design the algo.). Thoughts?

[jadeallenx]

Yeah that's good with me. I have been "thinking aloud" here and it is not all very simple or coherent

[paulo-ferraz-oliveira]

What do we do when there's more than one package manager? Test them one by one? e.g. centos has (yum, dnf). And on top of that we need the different package names per distro, with their corresponding probes.

[jadeallenx]

What do we do when there's more than one package manager? Test them one by one? e.g. centos has (yum, dnf).

I would say we expect the "default" method (so probably dnf on redhat like distros)

And on top of that we need the different package names per distro, with their corresponding probes.

Yeah this is exactly why I didn't want to get into this business in the first place 😂 I think we start with the package managers we currently support and make it easy for people to extend with a PR if they are so inclined.

[paulo-ferraz-oliveira]

I see. Maybe that's more feasible, to start with what we have. I was already listing package managers per "most popular Linux distro" and then I'd drill down. Do you know of any other issue that might be tied to this, too?

So you don't want an addition, right? You want a kinda code refactor (?)

[jadeallenx]

So you don't want an addition, right? You want a kinda code refactor (?)

Ideally I'd like to see a generic set of functions that scan for packages and make it somewhat obvious for people who want to support new distros what needs to be added (and where)

[paulo-ferraz-oliveira]

Yeah, something like

redhat
  rpm
    make
      _rpm_is_installed "make"

(?)

[paulo-ferraz-oliveira]

What distros should we aim for, to start?

Something like

mint
ubuntu
arch
slackware
debian
fedora
rhel
opensuse
freebsd

[jadeallenx]

Yeah, something like

redhat
  rpm
    make
      _rpm_is_installed "make"

(?)

I think it'd be something like

probe_method = id_distro
for pkg in $(get_distro_pkgs)
  _is_installed probe_method pkg

But I don't know if that's feasible. Open to other ideas, too. But to me that seems super clean.

[paulo-ferraz-oliveira]

I'm missing something. You need to identify:

• distro
• package manager
• package

right?

Or would you do without the package manager? And simply shove that into the probe?

[paulo-ferraz-oliveira]

e.g.

_KERL_PACKAGE_PROBE["redhat:make"]="rpm -q make"

We could go over the entries in the array and split distro from package.

[paulo-ferraz-oliveira]

Maybe rpm would be repeated a few times, but you get more flexibility. You might wanna just verify some file exists or something...

[paulo-ferraz-oliveira]

POSIX-sh has no associative arrays 😢 Kerl is POSIX.

Edit: as an added bonus, if we moved to Bash we'd get locally scoped variables 😄

[paulo-ferraz-oliveira]

As an example, the closest I have to this working is

_KPP__darwin__rebar3="which rebar3"

KPP stands for Kerl Package Probe.

The way I have it is generic, but potentially more repetitive, in writing the probes. If we wanna consider the probes not only linked to a package manager (as I suggested before) verbose is better.