Hide Forgot
Description of problem: Currently "dnf upgrade" does not work on Fedora 23 when packages khelpcenter-1:5.5.3-1.fc23 and kde-l10n-ca-15.08.3-1.fc23 are installed because these packages have file conflicts. For details of this example see bug #1299935. But I think there is a general problem: I think it dnf upgrade (and dnf automatic) should not abort the transaction at all, because this prevents updating of packages that are not related to the conflicting files and packages. This behaviour of dnf may have security consequences, because security updates are not installed, too! I think that dnf should instead ignore the conflicting packages, recalculate the list of packages to update again without the conflicting packages and dependencies of the conflicting packages. Then dnf should try again the remaining packages. Version-Release number of selected component (if applicable): dnf-1.1.5-1.fc23.noarch
This is clearly a packaging problem. I don't think it's a good idea to skip conflicting packages. It would bring a different set of security consequences. E.g. packages skipped instead of upgraded without admin noticing it (sure it may print warning but who reads warnings).
(In reply to Michael Mráka from comment #1) > This is clearly a packaging problem. This is a packaging problem, yes, but not _only_ a packaging problem, since one package can block updates of other packages that are complete unrelated to the package that causes the conflict. > I don't think it's a good idea to skip conflicting packages. It would bring > a different set of security consequences. E.g. packages skipped instead of > upgraded without admin noticing it (sure it may print warning but who reads > warnings). Sorry, but I don't agree. There are NO security consequences if packages are updated that are completly unrelated to the package that causes the conflict! I think, the _opposite_ is true: The _current_ behaviour of dnf is a security risk because security updates, that may be important and should be installed to fix security holes are not applied!!! For example, an update for kernel, openssh, openssl, apache, selinux, etc. are completly unrelated to kde-l10n packages and kde packages in general, they can be updated independently of kde. The right behavior of dnf would be to update packages that are compatible with the installed packages but without update packages that causes the error and those updates packages that depends on or requires these updated packages. Please think again about this.
I want to inform you that updates are blocked by package file conflicts more often than I think we can ignore it. After about tree days of dnf update was working, currently there are about 3000 packages pending for updates on our hosts, but they are not installed because of transaction error in dnf: file /usr/share/icons/hicolor/128x128/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 file /usr/share/icons/hicolor/16x16/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 file /usr/share/icons/hicolor/22x22/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 file /usr/share/icons/hicolor/32x32/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 file /usr/share/icons/hicolor/48x48/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 file /usr/share/icons/hicolor/64x64/apps/kwrite.png from install of kate-15.12.1-1.fc23.x86_64 conflicts with file from package kdebase3-3.5.10-39.fc23.x86_64 There is an updated package kate pending on bodhi, waiting for moved in stable updates repository, but all updates since about a week are pending, INCLUDING SECURITY UPDATES like that for openssh ! If a fix for packages causing the transaction error would be _usable_ (!) by dnf update within about one or two days, that delay would be acceptable. But it seems that it lasts at least a week, and often longer, until the transaction errors are resolved and dnf update installs all the pending updates. It seems that processing through bodhi has several delays in the release process. I think this is too long, especially for security updates!
(In reply to Edgar Hoch from comment #3) Since package kate is waiting for transmitting by bodhi for more than a day, I just tried a simple solution: I have excluded the packages that was listed as conflicting packages on the command line: dnf update -x kate -x kdebase3 The result: More than 3000 package which was waiting for update or installation (kernel for example) was installed. The solution was so simple a to try again without the conflicting packages. I don't see any reason why this could have negative security consequences...
I know this bug is closed but this is quite annoying when you get conflicts with packages from different repositories. Right now the transaction error doesn't include the repository so it can be a bit of a hassle to find out why this happens. Also, I think yum had the --skip-broken option which easily allowed one to upgrade the rest of the system.
Maybe there could be a list(s) of packages which to ignore when checking for conflicts, mentioned in /etc/dnf/ignored.d/*.conf Like there is /etc/dnf/protected.d/*.conf to protect packages not to be removed. I have these kind of conflicts often when some package has been installed with a help of alien-program. Like with Franz messenger recently. rpmfusion and other repositories does not provide a rpm package for Franz, so I use a deb-package with alien. See: https://forums.fedoraforum.org/showthread.php?313014-Help-me-in-installing-Franz-messenger-!&p=1812685#post1812685 The problem comes, when eg. a system is upgraded: "Error: Transaction check error: file / from install of filesystem-3.8-2.fc28.x86_64 conflicts with file from package franz-5.0.0_beta.18-904.x86_64" Or is the error in alien, which has made a package which claims it provides whole / directory-hierarchy. I could just mention franz in /etc/dnf/ignored.d to let dnf upgrade the system without problems. I would take an informed local risk with that then. Maybe even have "ignore" option in dnf-command: $ sudo dnf mark ignore franz
(In reply to zimon from comment #6) > Maybe there could be a list(s) of packages which to ignore when checking for > conflicts, mentioned in /etc/dnf/ignored.d/*.conf This would help in cases when you know that there exists an conflict, or if you install incompatible packages with something like alien. But it doen't help when there is a packaging problem in some of the repos. If doing automatic updates with dnf-automatic-install, an transaction test error aborts the whole dnf upgrade process, so NO package is upgraded, even those without any problems. Such packaging problems often lasts a longer time, sometimes many weeks, before it will be fixed, even if the maintainers will provide a fix very fast, because new packages got through bodhi with different states and time limits and during this the problem still exists. The problem still exists in Fedora 28! Actually, last night there was pending about 472 packages to update, including new kernel packages, on one many our systems, because Fedora has released package containernetworking-plugins-0.7.3-1.fc28.x86_64 which conflicts with installed package containernetworking-cni-0.7.1-1.fc28.x86_64. There is an updated package containernetworking-plugins-0.7.3-2.fc28.x86_64 available which fixes the problem, but containernetworking-plugins-0.7.3-1.fc28.x86_64 was pushed to stable 8 days ago, and containernetworking-plugins-0.7.3-2.fc28.x86_64 was pushed to stable 6 hours ago, e.g. today. That means that about 8 days no updates was installed, including security updates! I could run dnf upgrade manually, excluding the conflicting packages with --exclude=..., but usually I don't check dnf-automatic logs not all days, and it should run _automatic_ ... So, I still think that dnf should be enhanced to handle a transaction error like a package conflict that was detected earlier: dnf should exclude these conflicting packages and start again a dependency check and transaction check. This is because packaging problems has occured again and again during last years, including repos managed by Fedora (e.g. repo updates). Please think again about this. Here current logs of dnf-automatic from last night (sorry, some text is in german). I run "dnf upgrade" now again - now it has run successful installing all updates, because containernetworking-plugins-0.7.3-2.fc28.x86_64 was found in repos now. Sep 06 02:19:07 dnf-automatic[346338]: Transaktionsüberprüfung wird ausgeführt Sep 06 02:19:12 dnf-automatic[346338]: Transaktionsprüfung war erfolgreich. Sep 06 02:19:12 dnf-automatic[346338]: Transaktion wird getestet Sep 06 02:19:13 dnf-automatic[346338]: Die heruntergeladenen Pakete wurden bis zur nächsten erfolgreichen Transaktion im Zwischenspeicher abgelegt. Sep 06 02:19:13 dnf-automatic[346338]: Sie können zwischengespeicherte Pakete mit dem Befehl »dnf clean packages« entfernen. Sep 06 02:19:13 dnf-automatic[346338]: Fehler: Fehler bei der Transaktionsüberprüfung: Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/bridge aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/dhcp aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/flannel aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/host-device aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/host-local aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/ipvlan aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/loopback aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/macvlan aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/portmap aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/ptp aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/sample aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/tuning aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Datei /usr/libexec/cni/vlan aus der Installation von containernetworking-plugins-0.7.3-1.fc28.x86_64 kollidiert mit der Datei aus dem Paket containernetworking-cni-0.7.1-1.fc28.x86_64 Sep 06 02:19:13 dnf-automatic[346338]: Fehler-Zusammenfassung Sep 06 02:19:13 dnf-automatic[346338]: ------------- Sep 06 02:19:13 systemd[1]: dnf-automatic-install.service: Main process exited, code=exited, status=1/FAILURE Sep 06 02:19:13 systemd[1]: dnf-automatic-install.service: Failed with result 'exit-code'. Sep 06 02:19:13 systemd[1]: Failed to start dnf automatic install updates.
I am sorry but the request cannot be delivered and ensure integrity of the system at the same time. Sorry, but we cannot help here.
(In reply to Jaroslav Mracek from comment #9) > I am sorry but the request cannot be delivered and ensure integrity of the > system at the same time. Sorry, but we cannot help here. Why not? Currently, dnf already skips packages. If I run "dnf upgrade", I (may) get a list of packages: Dependencies resolved. Upgrading: ..... Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): ..... Skipping packages with broken dependencies: ..... Transaction Summary ..... Then the transaction starts, and of course, it should be do all or nothing. The detection of conflicting files between packages are currently run inside the transaction. Then, of course, the transaction should do nothing. BUT the detection of conflicting files between packages can also be run before the transaction starts. Then it would be possible to exclude conflicting packages, similar to the packages with brocken dependencies.