Re: yum 2.1.13 in updates-testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]