-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic dnf support #322
Comments
Hey there, @straight-shoota, sorry to bother, do you have any thoughts on this one? |
The installer seems to work just fine in an Amazon Linux 2023 image: Nevertheless, the suggested changes look reasonable. I'm not very familiar with the RPM ecosystem though, so I trust your judgement. Probably best to have both changes in separate PRs because they're not directly related. |
It does indeed work on I agree with your points. I'll make two separate PRs and rename the variable as you suggested. Thank you for your time! |
I was setting up a pipeline today on an amazon linux 2023-based container and got caught by surprise when the crystal installer script didn't work. I found it odd since I used it dozens of times to install the compiler on older amazon linux 2 containers, so I did a little debugging and found what was happening.
The script cleverly tries to infer the correct source from the installed package manager when the information provided by the os-release is not enough. The problem with this is that it assumes that every unknown distro using rpm will manage packages with yum. When an unknown distro uses dnf (like the newer versions of AL), the script just fails. Replacing
with
should solve the problem with distros using the full version of dnf.
The other problem that I found is that the script is not compatible with microdnf. The script currently tries to install the config-manager dnf command to add the crystal repo, which not only can bring a lot of unneded python depencies but also makes it incompatible with microdnf. Since microdnf will eventually replace the old python based dnf, I think supporting it is a good idea. By modifing
to use the same process used by _install_yum
both microdnf and dnf work as expected (tested the modified script on a Fedora 40 and a Fedora Rawhide containers).
Combining both modifications allows the script to successfully install crystal on
public.ecr.aws/lambda/provided:al2023
, which is based on fedora and uses microdnf. Is there a chance to see those changes being implemented? I could prepare a PR if there is interest on it.The text was updated successfully, but these errors were encountered: