Display a message on CentOS if EPEL isn't enabled and depexts aren't available - #4679
Conversation
| Some "On CentOS/RHEL, many packages may assume that the Extra Packages \ | ||
| for Enterprise Linux (EPEL) repository has been enabled. This is \ | ||
| typically done by installing the 'epel-release' package. Please \ | ||
| see https://fedoraproject.org/wiki/EPEL for more information" |
There was a problem hiding this comment.
We're going to need a number of these workarounds for different operating systems (e.g. Alpine's edgecommunity, Brew's custom taps and so on). Would it be feasible to move this into a package {message} entry somehow rather than hardcoding Fedora-specific logic in the client? Obviously, other opam-repositories other than OCaml's may not make this assumption as well.
There was a problem hiding this comment.
The logic here is being embedded in the section of the opam client which deals with the logic for specific package managers, so I think it is in the right place for now?
It's not feasible between now and releasing 2.1, no. At the moment, for EPEL specifically, this is fixing a regression in behaviour because of a poor decision in 2017 to handle this in opam-depext! All this PR is doing (the actual new code is only a tiny bit on an error message) is displaying this message if it thinks it might be helpful. We should definitely follow this up with better (and generic) tagging, or some such, of depexts, though.
My understanding is that the Alpine repos work much better because the error message from apk clearly explains what needs doing (i.e. this PR brings dnf up to apk's standard 🙂). ppas, custom taps, etc. would be a completely new feature - EPEL is an official repository system (as, again, if I understand correctly, edgecommunity is an official repo, it's just not necessarily enabled by default?).
|
(rebased to pick up a fix in #4678) |
d03f42f to
725ee63
Compare
The opam-depext plugin used to hoist the epel-release package to work-around this, but this is incompatible with checking the availability. The special-case installation of epel-release is somewhat unfortunate - it's now replaced with a guided approach suggesting what might need changing.
Provides the workaround for #4669 discussed last week. This PR temporarily sits on #4678, as it uses some of the refactorings - only 34d5caf is new.
With this patch, on CentOS without EPEL enabled you now see:
Most of the change is refactoring the existing API to separate the computation of what's happened from formatting the message (so that
OpamClientcan semantically what happened).I've only applied this to
OpamClient.install_tandOpamSolution.check_availability- I'm not sure if some of the other functions inOpamClientwant this or not.