Description of problem: Seems to be close to other reported bugs, but is different. If a package in an install list doesn't exist, dnf fails to install any package. Version-Release number of selected component (if applicable): dnf-1.0.0-1.fc22 How reproducible: Every time tried. Steps to Reproduce: 1.Verify espeak is not currently installed. 2.dnf install espeak foo 3. Actual results: [root@myplace ~]# dnf install espeak foo Last metadata expiration check performed 2:52:58 ago on Fri May 22 08:49:02 2015. No package foo available. Error: no package matched: foo [root@myplace ~]# Expected results: When yum is run: [root@myplace ~]# yum install espeak foo Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile * fedora: repo.atlantic.net * updates: repo.atlantic.net No package foo available. Resolving Dependencies --> Running transaction check ---> Package espeak.x86_64 0:1.48.04-3.fc21 will be installed < install messages > [root@myplace ~]# Additional info:
Hello, this is not a bug; it's a feature. Can you elaborate on the use case in which you are trying to install unneeded (because you don't mind if they are not installed) packages?
I'm not trying to install unneeded packages. These are packages installed and working on the previous version of the OS. When setting up a new machine or installing a new OS from scratch, I need to install many packages that are not in the default installation. I run a long script to install the required packages and configure the machine for my purposes. One of the many, many lines may be: dnf -y install foo foo1 foo2 fo3 foo4 foo5 foo6 goof-* fifo* If the foo6 package was discontinued or renamed or not available, then none of the other 10 or more packages are installed. I won't know this until I try to use one of them.
So, you'd rather install the rest and then resolve the problem that a package was discontinued or renamed - e.g. by finding an appropriate replacement? Please note that in such case it may happen that you'd have to replace e.g. foo1 as well because installing foo1 may make sense only with foo6 and you'd have to find a replacement for both foo6 and foo1. So, you'd have to remove foo1 and install the new replacement. I think that this workflow unnecessarily wastes your resources. Finding out that a package is not available, resolving the problem and installing the package after that is much better in my opinion.
So, you'd rather complicate the issue rather than fix a problem that doesn't exist in the application you forked. As you said, "Finding out that a package is not available, resolving the problem and installing the package after that is much better in my opinion." Problem is dnf doesn't indicate all the unavailable packages, only the first one it encounters on a line. That isn't acceptable to me, if it's acceptable to you, then long live yum.
(In reply to Tom from comment #4) > So, you'd rather complicate the issue rather than fix a problem that doesn't > exist in the application you forked. As I said: "I think that this workflow unnecessarily wastes your resources." > Problem is dnf doesn't indicate all the unavailable packages, only the first > one it encounters on a line. Well, if this is the problem, it's easily fixable. (dup of bug 1208918)
*** Bug 1232986 has been marked as a duplicate of this bug. ***
I have a post-install script that I run on a bunch of machines to install sets of packages. When I upgrade from one version of Fedora to the next, sometimes a package listed for installation is no longer available. In this case, the ideal behavior is to install the packages that are available, skipping those that cannot be installed. In my experience, some missing packages don't matter, and even the ones that do matter are low priority. In dnf, my script fails to install any packages if a single package does not exist, which leaves machines in a broken state. It's great to have the error in the output, so that I can search through logs to identify packages that need to be updated, but there should be a way to make this non-fatal. If I have a list of 1000 packages that need to be installed, and a single minor one is missing, then this behavior makes an otherwise low-priority nuisance into an urgent problem. I agree that the default behavior should be to abort, but it's problematic that there's no way to change the behavior.
By the way, this is closely related to bug #1197456. The rationale described on that bug ("All of them should be installed at some moment in the future but some of the packages may be broken/unavailable now so it's enough to install at least the rest of them now and wait for the rest to be fixed.") is essentially the same as the rationale for the behavior requested in this bug.
No, the rationale is not the same. Tom admitted that the package could have been also "discontinued or renamed". In that case, the package will never be "installed at some moment in the future". Andrew, let's track your request in the bug 1197456. In this bug, I'd rather hear why does Tom prefer to solve the problem *after* the installation rather than *before* (assuming that we will fix the bug 1208918).
I agree that there's a subtle difference in the two cases (a broken package vs. a discontinued package). I would like to be able to choose leniency in both cases. Some discontinued or renamed packages are minor annoyances or perhaps completely unimportant (for example, if a package was discontinued because it was subsumed by another installed package). In the end, a 99% working system is better than a completely non-working system. Not in every use case, but in enough use cases to warrant user choice with a command-line flag. As it is right now, it looks like I'll have to make my postinstall script run "dnf install -y" once for each package in the package install list, which will be ridiculously slow.
(In reply to Andrew McNabb from comment #10) > Some discontinued or renamed packages are minor annoyances or perhaps > completely unimportant (for example, if a package was discontinued because > it was subsumed by another installed package). I think that you can't assume so easily that the renamed package will be installed anyway. The same goes for the retired packages. Once python2 becomes unavailable, I believe that those people whose scripts call python2 would be very much annoyed that DNF assumes that they read mailing lists and that they must have ported all their scripts already.
I am not assuming at all that the renamed package will be installed anyway. I simply asserted that it sometimes happens. If a responsible user runs "dnf install --skip-missing", then of course they would look through the logs and notice that python2 is missing. The current behavior of dnf is the best default behavior, but I think you can't assume so easily that _all_ users would want installation to fail if a single package is missing.
(In reply to Radek Holy from comment #9) > No, the rationale is not the same. Tom admitted that the package could have > been also "discontinued or renamed". In that case, the package will never be > "installed at some moment in the future". > > Andrew, let's track your request in the bug 1197456. > > In this bug, I'd rather hear why does Tom prefer to solve the problem > *after* the installation rather than *before* (assuming that we will fix the > bug 1208918). The fact is, the problem isn't known *before* the installation. Only *after* the attempted installation would I know that packages weren't installed. Simple example of dnf run on a f21 box. I know we are talking F22 here, but it's the only example I could find without unnecessarily wasting my resources. # dnf -y install rsyslog-ng gpm vim lynx No package rsyslog-ng available. Error: no package matched: rsyslog-ng # NOTE: The gpm, vim, and lynx packages were not installed.
That must be just a language barrier. I meant *before* any package is installed on the system. The command has to be run to find out the problem anyway. But I believe that it's much more effective to get the error before anything is installed so I wonder why would you prefer to get the error after the installation if there is the risk that you would have to uninstall some of the packages which were just installed in order to resolve the problem, e.g. in this situation: * A requires P * B provides P and conflicts with C * C provides P and conflicts with B * D is no longer available * E is a good replacement for D but requires C * "dnf --skip-broken install A D" installs A and B * "dnf install E" fails * "dnf --allowerasing install E" uninstalls D and installs C and E instead of: * "dnf install A D" fails * "dnf install A E" succeeds (and it saves your bandwidth, time and disk space)
(In reply to Radek Holy from comment #14) > I wonder why would you prefer to get the error after the installation if there > is the risk that you would have to uninstall some of the packages which were > just installed in order to resolve the problem. Please share your work flow of solving problem of retired packages, Tom. I am for marking it as duplicate of bug 1197456.
(In reply to Jan Silhan from comment #15) > (In reply to Radek Holy from comment #14) > > I wonder why would you prefer to get the error after the installation if there > is the risk that you would have to uninstall some of the packages which were > > just installed in order to resolve the problem. > > Please share your work flow of solving problem of retired packages, Tom. I > am for marking it as duplicate of bug 1197456. If you look at comment #13 you will see that the applications being installed are not part of a particular group and are not related in any way. It is a list of packages that didn't get installed because dnf doesn't have the sense to process the entire command line before throwing in the towel. Radek Holy's comment #14 describes a confusing scenario of related or conflicting packages. That scenario may apply to a dedicated/experienced python or other programmer. Those folks should be able to handle the problem. I'm talking about the user that follows the advice to do a fresh install of a new fedora version. That user may be talented enough to write a script to reinstall their current packages. Imagine when nothing is installed because the first package in the package list is either misspelled or has been replaced. Now imagine 10 such commands. Now, maybe 40 packages didn't install. This whole thing is getting way out of control. I know the proper fix will prevail, so carry on, live long and prosper.
They might not be related at first sight but I'm sure that they share a lot of dependencies and that's when the situation described above may happen. My point is that even with --skip-install, you have to parse the output of the command, find the failing packages and find out what to do with these. If they are misspelled, you need to correct the mistake. With a discontinued package, you need to find a replacement. But it has already installed some dependencies that might conflict with the missing packages. Now, "dnf install missing-pkg" fails because it conflicts with these dependencies and you have already wasted your Internet connection with downloading the packages and wasted your time and disk space with installing them. And also, you need to find out how to install the replacement if neither "dnf install" nor "dnf skip-install" does work. On the other hand, using "dnf install" at the beginning will tell you the problem without the wasting of the resources, you'll fix the command and be happy. Anyway, it seems that you are not going to change your habits and since the "--skip-install" behaviour is already requested with a correct use case, let's close this as the duplicate of the bug 1197456. Let's see how soon you come back with the problem that "dnf install E" is failing (as described above). *** This bug has been marked as a duplicate of bug 1197456 ***
Sheesh! All these hypothetical cases of something that might go wrong but never does (I've been installing new fedoras forever and using a list of the rpms on the old fedora to make sure I update the new one to have as much stuff the same as the old as possible - not once has some hypothetical over the river and through the woods dependency screw up caused a problem). Dnf however, causes a BIG problem because it will only tell me about one missing package at a time. If you don't want to ignore the missing packages, then for God's sake list ALL of them, not just the first one. That would at least make it possible to use the feedback to remove the excess packages from the list all at once. The current behavior is like feeding a 12000 line program to a compiler and getting a single message at the end "syntax error". I'm now updating my f22 system by running dnf -y install one package at a time, which will apparently take most of the night to complete.
As I said, this is the bug 1208918. Adam has already submitted a patch.