Description of problem: DNF doesn't support the standard double-dash ("--") option-argument separator, which yum supported. This breaks yum compatibility and prevents safe invocation of DNF with arbitrary command arguments. E.g. if a program is expecting an arbitrary list of packages to install, it can no longer safely pass them to yum. Before it was possible to do this in Bash: yum install --assumeyes -- "${PACKAGE_LIST[@]" Now that doesn't work, producing this error message instead: No package -- available. Error: no package matched: -- Version-Release number of selected component (if applicable): dnf-0.6.5-1.fc23.noarch How reproducible: Always Steps to Reproduce: Execute "dnf install -- dnf" Actual results: No package -- available. Error: no package matched: -- Expected results: Using metadata from Fri Apr 24 16:46:28 2015 (0:19:58 hours old) Package dnf-0.6.5-1.fc23.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
Hello, thank you for the report. Strictly speaking, the man pages say that the synopsis is "dnf [options] <command> [<args>...]". So, anything passed after a "<command>" should be handled as an argument of the command. E.g. in case of the install command, anything after the "install" word should be considered a package specification. This means that there is no actual need for means that mark that no switches will follow. The command name serves that purpose. And also no command name starts with a dash. But I admit that although we don't (officially) support passing switches after the command name, it works (sometimes). So, I am not trying to say that we shouldn't support this separator. I just wanted to tell that so far, this is an RFE, not a bug. And unless we agree that we want to support using switches after the command name, the priority of the request is low.
Hello, Radek. I disagree that this is RFE. DNF seems to accept options after a command name perfectly fine, at least for "install", the most important case for us. Examples: dnf install --help dnf install dnf --help dnf install dnf -d 10 bash dnf install --assumeyes bash --assumeno This is a clear compatibility breakage. Yum supported this, DNF doesn't. This breaks sudo rule security. With yum you could rely on the fact that whatever is passed after "--" will only be interpreted as package name. With DNF you can't do that. Now you'll have to remove "--", opening yourself to, e.g. "--enablerepo=" being passed along with package names.
As I said, although it isn't (officially) supported, it works (sometimes).
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
It should be fixed automatically with DNF argparser refactoring using subparsers.
Great! Thank you, Jan! This change would be welcome. For now I have to fall back to yum.
Jan Silhan, could you please give an ETA for the fix? Thank you.
Fixed as a part of DNF 2.0 argument parser rewrite https://github.com/rpm-software-management/dnf/pull/474
Merged, will be part of DNF 2.0 release which will be released at some point soon.