Description of problem: I've used the following command to install packages in the past: sudo dnf install gstreamer{1,}-{plugin-crystalhd,ffmpeg,plugins-{good,ugly,bad{,-free,-nonfree,-freeworld,-extras}{,-extras}}} libmpg123 lame-libs which expands to: sudo dnf install gstreamer1-plugin-crystalhd gstreamer1-ffmpeg gstreamer1-plugins-good gstreamer1-plugins-ugly gstreamer1-plugins-bad gstreamer1-plugins-bad-extras gstreamer1-plugins-bad-free gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-nonfree gstreamer1-plugins-bad-nonfree-extras gstreamer1-plugins-bad-freeworld gstreamer1-plugins-bad-freeworld-extras gstreamer1-plugins-bad-extras gstreamer1-plugins-bad-extras-extras gstreamer-plugin-crystalhd gstreamer-ffmpeg gstreamer-plugins-good gstreamer-plugins-ugly gstreamer-plugins-bad gstreamer-plugins-bad-extras gstreamer-plugins-bad-free gstreamer-plugins-bad-free-extras gstreamer-plugins-bad-nonfree gstreamer-plugins-bad-nonfree-extras gstreamer-plugins-bad-freeworld gstreamer-plugins-bad-freeworld-extras gstreamer-plugins-bad-extras gstreamer-plugins-bad-extras-extras libmpg123 lame-libs Now, some packages from this list are not available in the repos, since the bash expansion tries to cover all possibilities and therefore includes some extras. Previously, and I'm not completely sure about this, DNF used to simply skip the unavailable ones and try to install the ones that it could. Now, it stops as soon as it finds the first unavailable package. This behaviour is undesirable, and is not how bash commands usually work. DNF should go through the list, work on the ones that exist and at the end of the transaction summary, list out ones that weren't available which is the previous behaviour for yum and I think used to be for DNF as well. Note that the list command works as expected: [asinha@cs-as14aho-2-herts-ac-uk SPECS]$ sudo dnf list gstreamer{1,}-{plugin-crystalhd,ffmpeg,plugins-{good,ugly,bad{,-free,-nonfree,-freeworld,-extras}{,-extras}}} libmpg123 lame-libs Last metadata expiration check performed 0:26:38 ago on Tue Jun 2 08:54:02 2015. Installed Packages gstreamer-ffmpeg.x86_64 0.10.13-15.fc22 @System gstreamer-plugin-crystalhd.x86_64 3.10.0-8.fc22 @System gstreamer-plugins-bad.x86_64 0.10.23-6.fc22 @System gstreamer-plugins-bad-free.x86_64 0.10.23-24.fc22 @System gstreamer-plugins-bad-free-extras.x86_64 0.10.23-24.fc22 @System gstreamer-plugins-bad-nonfree.x86_64 0.10.23-3.fc22 @System gstreamer-plugins-good.x86_64 0.10.31-13.fc22 @System gstreamer-plugins-ugly.x86_64 0.10.19-18.fc22 @System gstreamer1-plugins-bad-free.x86_64 1.4.5-2.fc22 @System gstreamer1-plugins-bad-free-extras.x86_64 1.4.5-2.fc22 @System gstreamer1-plugins-bad-freeworld.x86_64 1.4.5-2.fc22 @System gstreamer1-plugins-good.x86_64 1.4.5-2.fc22 @System gstreamer1-plugins-ugly.x86_64 1.4.5-1.fc22 @System lame-libs.x86_64 3.99.5-5.fc22 @System libmpg123.x86_64 1.19.0-2.fc22 @System Available Packages gstreamer-plugin-crystalhd.i686 3.10.0-8.fc22 fedora gstreamer-plugins-bad-free.i686 0.10.23-24.fc22 fedora gstreamer-plugins-bad-free-extras.i686 0.10.23-24.fc22 fedora gstreamer-plugins-good.i686 0.10.31-13.fc22 fedora gstreamer1-plugins-bad-free.i686 1.4.5-2.fc22 updates-testing gstreamer1-plugins-bad-free-extras.i686 1.4.5-2.fc22 updates-testing gstreamer1-plugins-good.i686 1.4.5-2.fc22 updates-testing lame-libs.i686 3.99.5-5.fc22 rpmfusion-free libmpg123.i686 but the install does not: [asinha@cs-as14aho-2-herts-ac-uk SPECS]$ sudo dnf install gstreamer{1,}-{plugin-crystalhd,ffmpeg,plugins-{good,ugly,bad{,-free,-nonfree,-freeworld,-extras}{,-extras}}} libmpg123 lame-libs Last metadata expiration check performed 0:27:15 ago on Tue Jun 2 08:54:02 2015. No package gstreamer1-plugin-crystalhd available. Error: no package matched: gstreamer1-plugin-crystalhd This is also inconsistent behaviour :( Version-Release number of selected component (if applicable): dnf-1.0.0-1.fc22.noarch How reproducible: Always Steps to Reproduce: 1. Listed above 2. 3. Actual results: Install fails pre-emptively, list works. Expected results: Install should work too - all commands should, ideally. Additional info:
Hello, this is not a bug; it's a feature. Do I understand it correctly that the package "gstreamer1-plugin-crystalhd" will never exist and you (or bash if you wish) put it there just as a side effect of having a simpler expression? Why do you think that this > is not how bash commands usually work ? E.g. "touch" and "rm" fails as well: $ touch a $ rm {a,b} rm: cannot remove ‘b’: No such file or directory $ echo $? 1 I'd rather consider the behavior of "dnf list" as a bug.
Ah, no that isn't what I'm saying. They "fail" in the sense that they give an error code. However, the do carry out the requested operation on the arguments that do exist. For example: [asinha@cs-as14aho-2-herts-ac-uk ~]$ touch a [asinha@cs-as14aho-2-herts-ac-uk ~]$ rm {b,a} rm: cannot remove ‘b’: No such file or directory rm: remove regular empty file ‘a’? y [asinha@cs-as14aho-2-herts-ac-uk ~]$ echo $? 1 [asinha@cs-as14aho-2-herts-ac-uk ~]$ What dnf does is - it *stops* at "b" completely - the first argument that isn't available - and doesn't go on to "a" at all. This is what I consider a bug :) I hope that clarifies the issue? Cheers, Ankur
Got it. Anyway, I believe that this is another case. In DNF, we consider the request as a single transaction. If one of the packages cannot be installed, the transaction cannot be performed. E.g. a script would not be able to determine which packages were skipped otherwise (without parsing the output). But, let's focus on your use case. Do I understand it correctly that the package "gstreamer1-plugin-crystalhd" will never exist and you (or bash if you wish) put it there just as a side effect of having a simpler expression? Or is it just that the package is not available at the moment?
It doesn't exist (unless a package of this name comes up in the future, of course), and yes, it's only turns up as a side effect of the simpler expression.
OK, would a "skip-install" plugin (which skips packages that cannot be installed) work for you? (bug 1197456)
Yeah. If I understand how DNF works, the two cases appear to be the same, so it would work here too. Thanks :)
*** This bug has been marked as a duplicate of bug 1197456 ***