Description of problem: As of writing, running 'crb enable' in a container leads to "No such command: config-manager." error: $ podman run -it --rm rockylinux:9 $ dnf install epel-release -y $ dnf update epel-release -y # epel-release-9-2.el9.noarch in Rocky Linux 9 $ crb enable Enabling CRB repo No such command: config-manager. Please use /usr/bin/dnf --help It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'" CRB repo is disabled $ Version-Release number of selected component (if applicable): epel-release-9-3.el9 How reproducible: Always, see above. Actual results: Running 'crb enable' in a container leads to "No such command: config-manager." error Expected results: Running 'crb enable' in a container does not lead to "No such command: config-manager." error Additional info: My proposal is to add "Recommends: dnf-command(config-manager)" to the epel-release RPM package. And "Recommends:" that people disliking "dnf-command(config-manager)" for whatever reason could still avoid it.
Nope, it should be a hard dependency. Shipping scripts broken is just a bad idea.
I'd be fine with it as a recommends, since it's optional to run the script. I brought up this issue when this update was in testing. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-de0e772ee0#comment-2603282
I agree with Neal on it being a hard dependency, unless we make the script provide a more helpful error message when dnf-plugins-core isn't installed.
Is the following proposal good enough for a more helpful error message? --- 8< --- --- /usr/bin/crb 2022-06-30 12:56:44.000000000 +0000 +++ /usr/bin/crb.error 2022-08-05 22:14:09.936885291 +0000 @@ -46,6 +46,11 @@ # Only RHEL has a repo with codeready in it, use subcription-manager subscription-manager repos ${command} ${crb_repo} else + # Determine if dnf-command(config-manager) is installed + if ! rpm -q --whatprovides 'dnf-command(config-manager)' > /dev/null 2>&1 ; then + echo "Error: Enabling/disabling CRB repo requires 'dnf-command(config-manager)' installed, aborting!" >&2 + exit 1 + fi # Everything else uses dnf config-manager dnf config-manager ${command} ${crb_repo} fi --- 8< ---
(In reply to Robert Scheck from comment #4) > Is the following proposal good enough for a more helpful error message? > > --- 8< --- > --- /usr/bin/crb 2022-06-30 12:56:44.000000000 +0000 > +++ /usr/bin/crb.error 2022-08-05 22:14:09.936885291 +0000 > @@ -46,6 +46,11 @@ > # Only RHEL has a repo with codeready in it, use subcription-manager > subscription-manager repos ${command} ${crb_repo} > else > + # Determine if dnf-command(config-manager) is installed > + if ! rpm -q --whatprovides 'dnf-command(config-manager)' > /dev/null > 2>&1 ; then > + echo "Error: Enabling/disabling CRB repo requires > 'dnf-command(config-manager)' installed, aborting!" >&2 > + exit 1 > + fi > # Everything else uses dnf config-manager > dnf config-manager ${command} ${crb_repo} > fi > --- 8< --- It's quick. It works. I like it. The only thing I think might be a problem is telling the users they need 'dnf-command(config-manager)' Anyone on this bugzilla would know how to fix that, but I think your average container user wouldn't know that they need to install dnf-plugins-core I know it's possible it might change in the future, but how about we change it to echo "Error: Enabling/disabling CRB repo requires dnf-plugins-core installed. aborting!"
Ah, right. How about even this: echo "Error: Please run: dnf install 'dnf-command(config-manager)'" >&2 echo " before trying to enable/disable the CRB repo. Aborting"'!' >&2 That allows copy & paste of the needed command for users.
I think we should still make dnf-command(config-manager) a Recommends, in addition to having the script fail cleanly. This should only require extra steps for users that explicitly disable weak deps. We could also have the script offer to install the package itself if it's missing, but I'm not sure that's the best idea.
Yes to both. I love the cut and paste idea for the error. And I agree that we should have Recommends.
I have updated the crb script, and done the Recommends in this pull request. https://src.fedoraproject.org/rpms/epel-release/pull-request/23 I have tested this on epel9. If people feel this is correct, I'll get it merged and built and do the same for epel8.
Here is the pull request for epel8 https://src.fedoraproject.org/rpms/epel-release/pull-request/24
FEDORA-EPEL-2022-9f2e716f60 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9f2e716f60
(In reply to Maxwell G from comment #7) > We could also have the script offer to install the package itself if it's > missing, but I'm not sure that's the best idea. Interesting thought! We could even add the following snippet right before determining if dnf-command(config-manager) is installed: --- 8< --- # Try to install dnf-command(config-manager) on interactive shells if ! rpm -q --whatprovides 'dnf-command(config-manager)' > /dev/null 2>&1 ; then [[ $- = *"i"* ]] && dnf install 'dnf-command(config-manager)' fi --- 8< --- And if the user decides to say "no" at the dnf call, crb still fails with the same error like on non-interactive shells. What I personally would like to avoid is 'dnf -y' though. Comments?
With the recommends in place I don't see a point in having the script attempt to install the plugin. The only time the condition would be met would be if someone intentionally avoids installing the recommends, in which case they won't be running this script.
FEDORA-EPEL-2022-9f2e716f60 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9f2e716f60 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-9f2e716f60 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.