If I use `dnf repolist` to get a list of repos, I cannot pass anything there to `dnf --disablerepo`, because `dnf --disablerepo` expects a URL but `dnf repolist` shows you the name of each repo, but not their URLs.
Hello, the `--disablerepo` option takes the repository id as an argument and `dnf repolist` shows for each repository its id (in a column "repo id") and name. So, you can take the repository id from `dnf repolist` output and pass it to the `--disablerepo` option. I'm closing this as not a bug, but don't hesitate to ask if you need more help.
That's *exactly* what I did, as I mentioned in the description. The problem was that --disablerepo expected a URL, not an ID.
Can you please provide steps to reproduce the issue and outputs of dnf (both for the `repolist` command and for the other one with `--disablerepo`)?
1. run `dnf repolist` 2. See that its output has no URLs in it, only IDs 3. run `dnf --disablerepo with one of the IDs from the output of `dnf repolist` 4. It doesn't work $ dnf repolist repo id repo name fedora Fedora 35 - x86_64 fedora-cisco-openh264 Fedora 35 openh264 (From Cisco) - x86_64 fedora-modular Fedora Modular 35 - x86_64 gh-cli packages for the GitHub CLI rpmfusion-free RPM Fusion for Fedora 35 - Free rpmfusion-free-tainted RPM Fusion for Fedora 35 - Free tainted rpmfusion-free-updates RPM Fusion for Fedora 35 - Free - Updates rpmfusion-nonfree RPM Fusion for Fedora 35 - Nonfree rpmfusion-nonfree-tainted RPM Fusion for Fedora 35 - Nonfree tainted rpmfusion-nonfree-updates RPM Fusion for Fedora 35 - Nonfree - Updates spideroak-one-stable SpiderOakONE Stable Distribution teamviewer TeamViewer - x86_64 updates Fedora 35 - x86_64 - Updates updates-modular Fedora Modular 35 - x86_64 - Updates $ dnf --disablerepo spideroak-one-stable usage: dnf [options] COMMAND [...] As you can see, `dnf --disablerepo` does not accept an ID, while `dnf repolist` only shows IDs.
Thank you for the additional information. The problem is that `--disablerepo` is an option that must be used with a command and disables a repo for just that command. If you want to disable the repository permanently, you either have to change its config file (by default in /etc/yum.repos.d/) or you can use the config-manager plugin and run: `dnf config-manager --set-disabled spideroak-one-stable`.
Yes, I eventually figured out a way to do it. The bug I'm reporting here is about the confusing UX: one `dnf` subcommand isn't able to consume the logical output of another because there is a mismatch in the data formats expected (id vs URL). The fact that `dnf config-manager --set-disabled` and `dnf --disablerepo` both exist but do different things and expect different data formats is super confusing.
Can you please provide an example with the mismatch? I.e. which subcommand requires URL instead of repoid?
`dnf --disablerepo` requires a URL instead of a repoid. `dnf repolist` give you a list of repoids instead of URLs.
dnf --disablerepo does use repoid, as does dnf config-manager --set-disabled, but dnf config-manager --add-repo takes a URL and dnf --repofrompath takes repoid,URL so that --disablerepo/--enablerepo can use a repoid for a URL. e.g. 1. "dnf --disablerepo=foo install baz" will attempt to locate and install baz from all repos except foo 2. "dnf --repofrompath=foo,https://example.com/repo/fedora/34/x86_64 --enablerepo=foo install baz" will temporarily add foo, enable it, and attempt to install baz with that repo enabled 3. "dnf config-manager --set-disabled foo" will disable the foo repo permanently 4. "dnf config-manager --add-repo https://example.com/repo/fedora/34/x86_64" will add that as a repo with the repoid of the URL 5. "dnf config-manager --add-repo https://example.com/repo/example-fedora-repo.repo" will download the repo configuration file and enable it
I submitted https://github.com/rpm-software-management/dnf/pull/1802 to improve the documentation here.
This has been merged and will be part of the next DNF release.
FEDORA-2022-e119fcc7d5 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e119fcc7d5
FEDORA-2022-e119fcc7d5 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.