Bug 1299989 - "dnf upgrade" should ignore packages that cause transaction error due file conflicts
"dnf upgrade" should ignore packages that cause transaction error due file co...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
23
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-19 11:50 EST by Edgar Hoch
Modified: 2016-11-18 08:47 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-25 07:57:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Edgar Hoch 2016-01-19 11:50:17 EST
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
Comment 1 Michael Mráka 2016-01-20 03:57:42 EST
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).
Comment 2 Edgar Hoch 2016-01-25 08:11:03 EST
(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.
Comment 3 Edgar Hoch 2016-01-29 11:50:10 EST
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!
Comment 4 Edgar Hoch 2016-01-30 12:08:17 EST
(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...
Comment 5 Christian Klomp 2016-11-18 08:47:16 EST
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.

Note You need to log in before you can comment on or make changes to this bug.