Red Hat Bugzilla – Bug 585194
yum does not take into account file conflicts with --skip-broken
Last modified: 2014-01-21 18:14:29 EST
Description of problem: Yum does not take into account file conflicts with --skip-broken. Yum knows what files are present in each remote package, it's in the filelists. This means it should know that files conflict (and therefore the update should be unselected) before it tries to to the test transaction where it's too late to modify the package list. With PackageKit, it means we show an error, and the user has to manually guess the correct package (and it's deps) to unselect and try (and usually try again, with _all_ the deps deselected) to get an update to succeed. It's bad enough that the use clicks 'Update' (after the simulation succeeded) and the failure isn't reported until all the packages are downloaded, usually when the user is doing something else entirely (breaking the workflow). Of course, this completely breaks the automatic updates feature that some people rely on. Steps to Reproduce: 1. Put a single package in the repo with a file-dep problem (happens weeklyish) 2. sudo yum update --skip-broken -y 3. Boom. No packages get updated. Actual results: [hughsie@hughsie-t61 yum]$ Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit Found 107 installed debuginfo package(s) Enabling livna-debuginfo: rpm.livna.org for 13 - i386 - Debug Reading repository metadata in from local files Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package gnome-icon-theme-extras.noarch 0:2.30.1-1.fc13 set to be updated --> Finished Dependency Resolution Dependencies Resolved =============================================================================== Package Arch Version Repository Size =============================================================================== Updating: gnome-icon-theme-extras noarch 2.30.1-1.fc13 updates-testing 605 k Transaction Summary =============================================================================== Install 0 Package(s) Upgrade 1 Package(s) Total size: 605 k Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Check Error: file /usr/share/icons/gnome/16x16/devices/drive-harddisk-ieee1394.png from install of gnome-icon-theme-extras-2.30.1-1.fc13.noarch conflicts with file from package gnome-icon-theme-2.30.1-2.fc13.noarch Expected results: "There are no updates" *or* Warning: gnome-icon-theme-extras could not be updated due to file conflicts Updating <other packages> [1/24] ...
Richard, we've talked about this before. In order to check filedeps beforehand we would need ALL of the checksums for ALL of the files in the pkgs in the repos. While we can add this information it would require a sizeable amount to download them. That's the crux of the issue. There are a couple of ways to make this a bit better: 1. look at the filelists everytime (expensive on its face) to see if there are any possible file conflicts. 2. download just the headers for those pkgs and look at the checksums - expensive and dodgy since a lot of mirrors don't support byte-ranges 3. add those pkgs to skip broken. OR have autoqa/rpmguard check for file conflicts on the server side and block them.
I took a look around to see what our counterparts in the debian world do when faced with a file conflict. this is what I could find http://www.mail-archive.com/debian-dpkg-bugs@lists.debian.org/msg07629.html essentially: if a file conflict happens and it is not also a pkg conflict - then proceed and dpkg should overwrite the old files with the new ones. Panu - any thoughts on this for rpm? I could definitely add a replacefiles transaction flag.
So my thoughts here: 1. Always checking file conflicts in yum is a horrible idea, it's a giant time sink that almost nobody is going to appreciate. 2. Doing what we've always said "auto QA should flag stuff which has file conflicts but not actual conflicts" is closer than ever to happening, and should fix everything in a nice way. 3. Doing multiple passes is about 1000% easier in a layer above yum, so if anyone wants to do that then feel free ... somewhere else. 4. Adding replacefiles will just remove the warning, not remove the problem.
1. conflicts of any file that matter is fairly uncommon, even if the repos are broken. if it were not for the expense of downloading the filelists we could easily check the pkgs in the transaction for any conflicting file. This goes back to what we were talking about before - we need some kind of metadata to let us grab per-pkg info - not per-repo. That would make it a good bit lighter. 2. If we coupled suggestion 1 with suggestion 4 so that if there was a potential conflict - we could warn about it then overwrite it. But you're not wrong about it being a time sink. It'll definitely absorb some time to check all files in the transaction vs each other and versus the rpmdb. rpm maintainers - y'all have any input?
(In reply to comment #2) > I took a look around to see what our counterparts in the debian world do when > faced with a file conflict. > this is what I could find > > http://www.mail-archive.com/debian-dpkg-bugs@lists.debian.org/msg07629.html > > essentially: if a file conflict happens and it is not also a pkg conflict - > then proceed and dpkg should overwrite the old files with the new ones. > > Panu - any thoughts on this for rpm? I could definitely add a replacefiles > transaction flag. Err... looks like a recipe for disaster to me. AFAICS based on the above, dpkg does just what rpm does: abort at file conflicts unless specifically overridden by the user and that's how it should be - the overwrite-behavior was *requested* but turned down. In this particular case, overwriting conflicting icons caused by a packaging bug might be a fairly harmless case but rpm can't go making such assumptions, a similar packaging bug could just as well trash a critical file and leave the system unbootable in worst case. Oh and btw, the repodata filelists dont have sufficient information to perform file conflict resolution the way rpm does it, at least file colors (needed to calculate multilib conflict resultion on elf files) is missing. And you really dont want to do the file conflict chekcing in yum anyway, it gets already done twice for a transaction (once for the test-transaction, second time for the actual transaction), adding an inevitably slower third round at yum level is not going make anybody happier. Within Fedora, the auto-QA testing is the best option to ensure these packaging bugs get caught early. But that doesn't stop third party repos etc from having occasional unintended file conflicts. Me thinks it'd be best if yum suggested filing a bug and offered a workaround (in spirit of "try with --exclude=conflicting-package").
Panu, A coupl of things - I know the filelists lack the info - I was suggesting a not-yet-invented metadata to deal with that. One specific point I'd like to ask - since it is not very important when man pages/icons/docs conflict - would it be possible to have a file conflict option in rpm to proceed/overwrite if the conflict is JUST a non-binary/library file? Just emitting a warning. That way we're still bailing on binary/library conflicts but not for stuff like man pages. If it were at the rpm layer it wouldn't even require any additional metadata. Thoughts?
It's a slippery slope if there ever was one. The only remotely reliable way of doing it would be path based, file type detection by contents is far too unreliable. I dont want my manual pages etc to be randomly overwritten by something else due to sloppy packaging even if it doesn't literally break the system, and I doubt users except that either. It also will cause inconsistent install/verify behavior: if it installs then how can it conflict (which it would on verification)? Just say no.