Comments (21)
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
from kerl.
Support this Linux variant by submitting a PR to https://github.com/kerl/kerl
My favorite bit 😄
from kerl.
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.
from kerl.
Yeah that's good with me. I have been "thinking aloud" here and it is not all very simple or coherent
from kerl.
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.
from kerl.
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"
from kerl.
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.
from kerl.
Thanks for the table @skwerlman that's super helpful
from kerl.
@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?
from kerl.
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.
from kerl.
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.
from kerl.
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 (?)
from kerl.
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)
from kerl.
Yeah, something like
redhat
rpm
make
_rpm_is_installed "make"
(?)
from kerl.
What distros should we aim for, to start?
Something like
mint
ubuntu
arch
slackware
debian
fedora
rhel
opensuse
freebsd
from kerl.
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.
from kerl.
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?
from kerl.
e.g.
_KERL_PACKAGE_PROBE["redhat:make"]="rpm -q make"
We could go over the entries in the array and split distro from package.
from kerl.
Maybe rpm would be repeated a few times, but you get more flexibility. You might wanna just verify some file exists or something...
from kerl.
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 😄
from kerl.
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.
from kerl.
Related Issues (20)
- fatal error: 'x86/x86assembler.h' file not found (macOS Ventura / Sonoma) HOT 1
- kerl sets REBAR_CACHE_DIR and this changes the rebar3 template directory behavior HOT 5
- zsh autocompletion failed
- `activate` breaks `man` for non-OTP man pages HOT 4
- kerl cannot be build on FreeBSD14. HOT 3
- Add Perl5 to common_ALL_BUILD_BACKEND_git_pkgs or _KPP_alpine_pkgs HOT 6
- Warning checking build packages on Pop OS HOT 2
- Update to allow generating documentation from OTP 27 on HOT 8
- Add more info. to the build/install log file
- Cannot extract OTP release tarball during Kaniko build HOT 5
- install fails in megaco_flex_scanner HOT 3
- FTB docs HOT 3
- Ubuntu 24.04: kerl generates a warning for non-existing libncurses5-dev package HOT 7
- Unable to install man pages HOT 1
- Over-optimized for happy path in "Probe failed for libncurses5-dev" warning. HOT 4
- Unable to install man pages for OTP 27 HOT 2
- Kerl fails to build erlang 23.3.4.18 on Fedora 40 HOT 2
- configure: error: C compiler cannot create executables HOT 6
- Please add a KPP for Oracle Linux 9, i.e release_id "ol" HOT 7
- kerl upgrade always upgrading HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kerl.