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

Re: yum cannot deal with "multilib" updates again - sigh!



On Fri, 3 Aug 2007 12:25:13 -0600, Michal Jaegermann wrote:

> With rawhide eventually "unplugged" an attempt to run 'yum update'
> resulted in the following:
> 
> Error: Unresolveable requirement scrollkeeper for gucharmap
> Error: Unresolveable requirement scrollkeeper >= 0.3.11 for gnome-user-docs
> Error: Unresolveable requirement scrollkeeper >= 0.1.4 for gnome-media
> Error: Unresolveable requirement scrollkeeper for gnumeric
> Error: Unresolveable requirement scrollkeeper for gconf-editor
> Error: Unresolveable requirement scrollkeeper >= 0.3.4 for gnucash-docs
> Error: Unresolveable requirement scrollkeeper for gthumb
> Error: Unresolveable requirement scrollkeeper for fast-user-switch-applet
> Error: Unresolveable requirement scrollkeeper for ggv
> Error: Unresolveable requirement scrollkeeper for gnome-utils
> Error: Unresolveable requirement scrollkeeper for yelp
> Error: Unresolveable requirement scrollkeeper for totem
> Error: Unresolveable requirement /usr/bin/scrollkeeper-update for gtkam
> Error: Unresolveable requirement scrollkeeper for gdm
> Error: Unresolveable requirement scrollkeeper for gtk-doc
> Error: Unresolveable requirement scrollkeeper for gnome-terminal
> Error: Unresolveable requirement scrollkeeper for libgnomedb-devel
> Error: Unresolveable requirement scrollkeeper for eog
> Error: Unresolveable requirement scrollkeeper for rhythmbox
> Error: Unresolveable requirement scrollkeeper >= 0.1.4 for printman
> Error: Unresolveable requirement scrollkeeper for gnome-pilot
> Error: Unresolveable requirement scrollkeeper for libgnomedb
> 
> and an update clearly bailed out leaving no further clues what
> may be the problem; especially that scrollkeeper-0.3.14-11.fc7,
> not that surprisingly, is present on the system.
> 
> Only further detective work revealed that the above is a result
> of a yum attempt to replace scrollkeeper.x86_64 with rarian.i386
> (although rarian.86_64 is also mentioned in a transaction too and
> rarian.i386 is definitely not wanted).  Excluding 'rarian' allowed
> to proceed and I can deal with that issue later.
> 
> I believe that this is one more example of a well known bogosity
> but if another bugzilla report is desired I can add one.

It is not just a multi-lib problem, but also affects plain i386.
The Obsoletes/Provides in rarian and rarian-compat are not in the
same package.




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