Description of problem: I have a 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. With yum, I could get this behavior with "yum install --skip-broken package1 package2 package3"; in this case, if "package3" is unavailable, "package1" and "package2" will still be installed. In dnf, the "--skip-broken" option is no longer available, and my script fails to install any packages if a single package does not exist. This leaves machines in a broken state. I may be missing some way to reproduce the behavior of "--skip-broken". Specifically, there should be some way to make a non-existent package a non-fatal error. I have been unsuccessful in finding such an option. Version-Release number of selected component (if applicable): dnf-0:1.0.0-1.fc22.noarch How reproducible: Always. Steps to Reproduce: 1. dnf remove mutt 2. dnf install asdf mutt Actual results: The mutt package is not installed in step 2. Expected results: Given some appropriate option to dnf, the mutt package should be installed even though asdf does not exist. Additional info:
I realized that this was the default behavior in yum (no association to the --skip-broken option), so I changed the bug title.
This is a duplicate of the bug 1224485. It isn't still clear to me why would one like to continue even if some of the packages cannot be installed. Especially if the one is a script. If the package is no longer available, then you need to find a replacement, doesn't you? Isn't it better to resolve this problem before the transaction is performed? Otherwise it may happen that some of the installed package would have to be uninstalled again when you find the resolution for the problem. *** This bug has been marked as a duplicate of bug 1224485 ***
Radek, if a single package is missing, it may not be a big deal at all. For example, two packages may have merged, or some rarely used package may no longer exist. It's good to be aware of these errors, but packages that end up being missing are usually not important enough to be worth leaving a system 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.
Maybe in the best case... I'd argue that it does not leave you in a broken state assuming that the upgrade went well. I'd rather say that installing the available packages and skipping the unavailable ones moves you into a broken state since the package manager claims that everything went well but the system is not in the state which was requested. Anyway, since I don't think that this use case is something we should support (and thus find the correct solution) and since there is already a request for --skip-broken, let's mark this rather as a duplicate of that bug. *** This bug has been marked as a duplicate of bug 1197456 ***
There are different degrees of brokenness: 1) If I can't ssh into a machine, then it is in a very broken state. 2) If I can't install some package that I use once a year, then the machine is in a slightly broken state (which I can easily fix by scanning my logs). 3) If I can't install a package that was retired because it was merged into some other installed package, then the machine is not in a broken state at all. A user of DNF should be able to choose what types of brokenness they care about. Right now, DNF treats all of these cases as equally broken, which just isn't true.
In that case, I'd run two commands. Using the first one, I'd install the critical packages (i.e. SSH). Using the second one, I'd install the rest. BTW, if there were some dependency problems of SSH, --skip-broken wouldn't tell you about that (unless you parse the output which is not recommendable). Also, I believe that if the system wasn't broken before the upgrade (i.e. SSH was installed), the upgrade shouldn't break it (i.e. uninstall SSH). If it does, it must be a bug.
Sure, you could do a single command with the critical packages. But the less critical packages would have to get installed individually, with a single dnf run for each package. This is just to slow to be a feasible approach. Furthermore, it's impractical to force this distinction on all users of dnf. People have a variety of workflows and needs and tradeoffs.
No, I'd install the rest together using a single command as well. But since they are not critical, I'd be fine if the command fails and if I had to fix the command so that it wouldn't fail again in the future. The difference is that if the first command fails, I know that I have to take a look immediately. On the other hand, if the second command fails, I know that I can fix it later.
So that's what you would do. Do I _have_ to do it the same way as you?
No, feel free to use the feature requested in the bug 1197456 if you wish.
Thanks. That feature would be great!