Dear all, before hell breaks loose and all kind of conspiracy theories dwell up again ;) There is a bug in yum up to yum 2.1.12 which break packages that are split during their evolution. This affects ATrpms in a greater extend than all other repos. This post will detail on this. Please point people with the below mentioned symptoms to the archives of this post. The bug in yum ============== https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144376 http://bugzilla.atrpms.net/show_bug.cgi?id=289 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140832 Consider a package foo-1.0-1 with some "bar" Provides (e.g. Provides: bar). A packager decides to split off some part of foo into a foo-bar package. The new foo-bar package should provide itself "bar" and not anymore the foo package. So this will result in two new packages, foo-1.0-2 not providing "bar" anymore and foo-bar-1.0-2 providing "bar". A package resolver should detect that foo is going to be upgraded, but the upgraded foo is missing the "bar" provides. It should then seek in the remaining set of packages for something offering "bar" and find foo-bar. The remaining set of packages should be the set of packages that are not obsoleted/conflicted/upgraded by the current rpm transaction or more precisely the rpm database after the current transaction's ending. The last thing is what yum does not deal with properly. It does all the steps that are mentioned, but when it comes to seek "bar" in the "remaining set of packages" it tests it also against the to-be-upgraded foo-1.0-1, which should not happen. Thus yum erroneously adds foo-1.0-1 as a dependency resolution to the upgrade transaction to foo-1.0-2 and both new and old packages are to be installed. This of course leads to a conflict and the end user is presented with > Transaction Check Error: file /some/file conflicts between attempted installs of foo-1.0-1 and foo-1.0-2 Why it mostly affects ATrpms: ============================= ATrpms is a repo that lays great emphasis upon compatibility, even though the above conflicts have led many people to assume ATrpms is not even compatible to the Fedora Core base repo. During the last years an increasing issue between rpos was that some repos were using libfoo.so.1 and others libfoo.so.2. There are two ways to solve this: o force all repos into using the same libfoo package. This is not a proper solution, since different repos have different needs. o provide compatibility packages for shared libs like Mandrake/Debian are doing. The libfoo.so.1* libs get into a package called libfoo1 and thos of libfoo.so.2* into libfoo2. Both are installable concurrently, so there is both forward and backward compatibility. It is a separate discussion whether Fedora Core itself should generally use this idom of splitting off runtime components like shared libs into their own package and if there is interest in going into further detail on this please don't hijack this thread to discuss this (open up a new thread on fedora-devel or repo-coord, if you like, I'm all for doing so!). But for ATrpms' goals of multi-repo compatibility it is required, otherwise a lot of repo combinations would have failed (check the gpgme, flac etc. library so bugs that were fixed by adding ATrpms as a repo to the set!), and will fail as soon as one repo decides to upgrade libfoo to a version that bumps up the major lib version. The packages potentially affected are (that's the list of package providing compatibility packages): a52dec alsa-lib flac fontconfig freetype gd glib2 howl libgal2 libsndfile libsoup libxml2 libxslt lineak openh323 openh323-janus openh323-pandora openjade openquicktime pango pwlib rpm smart xosd xvidcore What to do ========== o Since yum fails in its automatic dependency detection, do it yourself and tell yum what to do like yum install foo-bar foo for the example above. Some packages have more than one split out package, so this may be cumbersome and not quite what the end user expects. o Use another dependency resolver like apt (does not work on multilib systems) and/or smart (very early beta stadium). All resolvers are concurrently installable and can be used on the same system interchangeably (but of course not in parallel). o avoid using repos that have split out packages. That's mainly ATrpms today, but any repo including updates-released may split packages (and has done so in the past), so that's certainly the least welcome solution. According to the yum author, Seth Vidal, current yum CVS code may already have the proper check to fix this. I had a look as I would have packaged a CVS version of yum to offer on ATrpms to get over this bug, but there are too many changes (looks more like yum 2.2 or yum 3.0): # cvs -q diff -ud -r yum-2-1-12 | wc -l 1518 I hope Seth will soon find the proper fix to release a yum 2.1.13 that deals with it. Conclusion ========== o Any statements on ATrpms doing a lock-in on its packages by providing artificial conflicts are not to be taken seriously. o End users are quite dissatisfied that ATrpms does not work with the main dependency resolver of Fedora Core, and some tend to find comfort in reasons like the above. o My recommendation for non-x86_64 is to use apt until this bug is fixed. "So, once again, you are saying that ATrpms has no bugs, huh?" No, ATrpms has enough bugs to deal with, only not this one :) Thanks for reading thus far! :) -- Axel.Thimm at ATrpms.net
Attachment:
pgprTlUpD9kO5.pgp
Description: PGP signature
