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

Re: dependencies/conflicts on regular Fedora 10

On Tue, 03 Mar 2009 08:55:54 -0700, Phil wrote:

> This is supposed to happen.  yum is doing its job 
> protecting you from making mistakes.  Furthermore, this OFTEN happens 
> when mirrors are not in sync, which cannot be controlled.

That theory is broken. First of all, look at this:


What is it? A pkg group update from _last year_ for:
  digikam, kipi-plugins, kphotoalbum, kdegraphics

It's the one that changed from libkipi.so.5 to 6 in kdegraphics
while providing the corresponding rebuilds of digikam'n'others.

Now, Antonio's msg mentions a kernel from Nov 2008 and digikam from stock
F10 (Oct 2008), so perhaps no updates have been applied at all due to
unknown problems or misconfiguration. His truncated Yum output contains

  Missing Dependency: libkipi.so.5()(64bit) is needed by ...

What does that mean? Earlier in the Yum output one could have
seen that Yum mentioned availability of some updates (!), including one
for kdegraphics, the package that bumps libkipi to libkipi.so.6.

Back to your theory. A mirror would either have metadata about
a package offering libkipi.so.6 or old/out-of-date metadata. If it
knows about libkipi.so.6, however, it knows also about the related
rebuilds, such as digikam and kipi-plugins. Why would it keep the
old digikam* from F10 if the repo contains the FEDORA-2008-11798

> For this very reason, the yum plugin: skip-broken was written.
> But as you yourself admitted, trying again later, when either the mirror 
> finished syncing, or you used a different mirror, all worked as you 
> expected.

You might want to think about other scenarios where mirrors or multiple
repos can get out-of-sync.

> If, after several days of broken dependencies, you should have done as 
> the previous poster suggested and provided help to the maintainers, who 
> may have actually messed up a package.  Hey, it does happen.

Well, it's not in the Fedora 10 broken deps report.

> So how do you tell whether it really is broken?  Wait and retry for a 
> day or two.

No, examine the problem with a few repo queries to find out what
exactly is wrong.

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