Red Hat Bugzilla – Bug 504764
--skip-broken doesn't handle file conflicts
Last modified: 2014-01-21 18:09:47 EST
Created attachment 346993 [details] yum-log.txt rpm-4.7.0-1.fc11.i586 yum-3.2.22-5.fc11.noarch In some circumstances, "yum -y update --skip-broken" will still fail because of file conflicts in the test transactions. It would be useful if those could automatically be skipped, so PackageKit becomes useful for when those cases occur.
yum doesn't have the data to know about file conflicts, packages which file conflict should also explicitly conflict. There is some test code which will flag packages for rel-eng, as part of auto-qa, so hopefully this will get fixed for Fed-12.
That doesn't help when the packages that conflict aren't in the same repo (in this case, plugins transitioning from gstreamer-plugins-bad in RPMFusion to gstreamer-plugins-good in Fedora).
If you're making packages for fedora which do not comply with fedora's packaging guidelines then you cannot rely on features like --skip-broken to be useful in that situaton. We cannot add the necessary checksum information for ALL files to the file metadata w/o exploding the size of the file metadata by at least 2-3x its current size.
When the test transaction runs, the packages are already on the local disk. You don't need metadata, you have the actual data...
When the test transaction runs, depsolving has already finished. See: bug#502277 for a similar request, which can't be done this way for the same reason. And when files move between -good and -bad, the newer package should be conflicting with the older package ... this is still easy to do even when you are dealing with Fedora and rpmfusion.
Except that I'm sitting in front of a computer that's got more raw power than my brain at handling the thousand of files in the packages I need to update, and it can't seem to make life easier for me by ignoring package that would conflict. So it's not really NOTABUG, but rather CANTFIX, because of the way the yum maintainers expect it to run. FWIW, bug 502277 comment 1 says: "we only find out at #4 ... which is really late, so it would be much harder to do this. " So it's much harder and not impossible. bug 502277 comment 4 also says: "a pkg failing the gpgcheck is a security issue, not a depsolving issue." So I'm not really sure what's being argued, except the fact that you're not interested in doing the work. (FWIW, this bug is waiting on the gstreamer-plugins-good F11 candidate update to be released, but it's besides the point).