On Sat, 05 Feb 2005 22:57:28 -0500, Phil Schaffner wrote: > > > Looks like a packaging conflict from using multiple repositories to > > > me. I don't see how this qualifies as a yum problem considering that > > > yum isn't going to downgrade packages as a matter of design. > > > > synaptic requires libapt-pkg-libc6.3-6.so.0, which is only provided by > > apt-0.5.15cnc6-12.r362 in Phil's configured set of repositories. yum > > decides to take that one, but then realises that a higher version of apt > > is installed already and does not come from the enabled repositories. > > That's not a conflict, but an inconsistent repository configuration. > > Deliberately disabled 3rd party repos to test new yum and new Extras > repo. Seems yum should ideally notice the conflict in apt versions > earlier in the process, before asking the user to confirm the upgrade > (or should I say downgrade?). Again, there is no immediate conflict, _if_ your already installed version of apt provides libapt-pkg-libc6.3-6.so.0, regardless of where it comes from. In that case, the installed apt package would suffice, and yum need not add a different version from the enabled repositories into the transaction set. Depending on where and how the other apt package was built, it can be fully compatible. It's an inconsistency, though, in which packages you have installed and run, and which enabled repositories you fetch software from. There is no guarantee that the package is compatible. Generally, package dependencies on package capabilities and package contents would need to be much more strict to really assure when another package would be equivalent or compatible, respectively (you can sometimes see this with dependencies on virtual provides and path names, for instance). Dunno whether it's feasible to make Yum offer a downgrade as in "You have newer versions of packages installed which are not from the enabled set of repositories. To fix this inconsistency, do you want to replace them (y/n)?" ;o) > I get the same failure with ATrpms, > FreshRPMS, Dag, NR, NewRPMS, locally-built and Macromedia (my usual > [excessive?] set of 3rd party repos) added to the mix. Only way to > avoid the conflict/error seems to be to remove Extras - in which case, > result is "No Packages marked for Update/Obsoletion". > > Looks like Extras does not play nicely with ATrpms, FreshRPMS, ... any > more than Fedora.US did - or vice versa. Perhaps the situation will > improve now that Extras is on the Red Hat server. Otherwise, will just > stick with the "compatible" set of repos plus home-built where required. The solution is simple and just like it's done with Fedora Core. If there's something in Fedora Core which should change, try to get the changes applied in Fedora Core. Replacing packages and forking development can turn out to be interesting for testing purposes, but is no long-term solution. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.760_FC3 loadavg: 1.19 1.26 1.11