Description of problem: When trying to update package squid in rawhide (from squid-4.13-3.fc34) one gets: Error: Transaction test error: file /usr/share/squid/errors/es-mx from install of squid-7:5.0.5-2.fc35.x86_64 conflicts with file from package squid-7:4.13-3.fc34.x86_64 file /usr/share/squid/errors/es/ERR_ACCESS_DENIED conflicts between attempted installs of squid-7:5.0.5-2.fc35.x86_64 and squid-7:5.0.5-2.fc35.x86_64 file /usr/share/squid/errors/es/ERR_ACL_TIME_QUOTA_EXCEEDED conflicts between attempted installs of squid-7:5.0.5-2.fc35.x86_64 and squid-7:5.0.5-2.fc35.x86_64 ..... and so on for every file from /usr/share/squid/errors/es/. This breaks any update transaction where squid was involved. As all files in /usr/share/squid/errors/es* are really the same it is understandable that a new version attempts to replace some of those by symlinks. The issue is that a straight replacement will not work with errors like above. Version-Release number of selected component (if applicable): squid-5.0.5-2.fc35 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Looks like RPM issue: https://bugzilla.redhat.com/show_bug.cgi?id=1936422
(In reply to Luboš Uhliarik ✈ from comment #1) > Looks like RPM issue: https://bugzilla.redhat.com/show_bug.cgi?id=1936422 Yes, it looks that way. The problem is that this fails in a dnf transaction check. No idea about internal details but at this stage does %pretrans have even a chance to run? At this moment the only workaround seems to be to remove the old package before installing a new version. This does not seem to be onerous with squid but with other packages may turn out to be quite difficult.
Yeah, there are several workarounds: 1) remove old squid and install new version 2) rm /usr/share/squid/errors/es-mx && dnf update squid 3) rpm -Uvh squid-5.0.5-3.x86-64.rpm The problem is, that rpm during transaction test is wrongly assumes that there are conflicts between the files.
FEDORA-2021-fc6ff9375d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-fc6ff9375d
FEDORA-2021-fc6ff9375d has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-fc6ff9375d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fc6ff9375d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-fc6ff9375d has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #6) > FEDORA-2021-fc6ff9375d has been pushed to the Fedora 34 stable repository. > If problem still persists, please make note of it in this bug report. As for now I see in rawhide: Running scriptlet: squid-7:5.0.5-4.fc35.x86_64 1/1 Preparing : 1/1 Transaction couldn't start: file /usr/share/squid/errors/es-mx from install of squid-7:5.0.5-4.fc35.x86_64 conflicts with file from package squid-7:5.0.5-3.fc35.x86_64 Error: Could not run transaction. It looks like the same problem. In squid-7:5.0.5-3.fc35.x86_64 this /usr/share/squid/errors/es-mx is a directory, so one has to try harder than in comment 3 advice. After an update /usr/share/squid/errors/es-mx ends up as a symlink.
(In reply to Michal Jaegermann from comment #7) > (In reply to Fedora Update System from comment #6) > > FEDORA-2021-fc6ff9375d has been pushed to the Fedora 34 stable repository. > > If problem still persists, please make note of it in this bug report. > > As for now I see in rawhide: > > Running scriptlet: squid-7:5.0.5-4.fc35.x86_64 > 1/1 > Preparing : > 1/1 > Transaction couldn't start: > file /usr/share/squid/errors/es-mx from install of > squid-7:5.0.5-4.fc35.x86_64 conflicts with file from package > squid-7:5.0.5-3.fc35.x86_64 > Error: Could not run transaction. > > It looks like the same problem. In squid-7:5.0.5-3.fc35.x86_64 this > /usr/share/squid/errors/es-mx is a directory, so one has to try harder than > in comment 3 advice. After an update /usr/share/squid/errors/es-mx ends up > as a symlink. Hi Michal, this issue occurs only if you try to update from 5.0.5-3 to 5.0.5-4. If you update from older squid, it should work without any issue. In case you have squid 5.0.5, please just uninstall/install it manually.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
I'm closing this issue since updating squid to version >= 5.0.5 should work without any issue. In case you are experiencing this issue, feel free to reopen this bug.