Mailinglist Archive: zypp-devel (230 mails)

[Michael Matz <matz@xxxxxxx>]

Hi,

On Mon, 11 Feb 2008, Michael Matz wrote:

> > 1184 Probleme:
> > Problem: yast2-pkg-bindings-2.16.12-15.3.x86_64 is not installable
> > Problem: libzypp-4.2.1-2.2.x86_64 is not installable
> > Problem: zypper-0.9.6-5.9.x86_64 is not installable
> > .....
> >
> > Not suprisingly x86_64 is not installable here
>
> Probably an artifact of the update algorithm giving an insane job queue to 
> the solver (you maybe can transform the logfile of zypp with the attached 
> script into a part of the <trial> element of XML testcases).  Probably 
> that job queue explicitely contains "please install this x86-64 package", 
> well, garbage in, garbage out.

That's indeed the problem.  Somehow 
Helper::findUpdateItem->LookForUpdate::operator() (and also the use in 
Resolver::doUpgrade, at around line 417) of Arch::compare think that 
x86_64 is better than i586.  From your logfile:

2008-02-11 11:10:06 <1> desdemona(27804) [zypp] 
ResolverUpgrade.cc(doUpgrade):384 item 
I__s_[S73018:1]sat::solvable(30795|kdebase3-SuSE-11.0-41.i586){@System} is 
installed, candidate is 
U__s_@[S73019:1]sat::solvable(21355|kdebase3-SuSE-11.0-44.x86_64){Factory}

That string is printed only after Helper::findUpdateItem returned the 
x86_64 one for your installed i586 one, although it checks for 
architecture.

Due to the idiosyncratic implementation of Arch I can't figure out 
immediately where the error is.

It's the case that i586 is compatible for x86_64 as target.  And the 
Arch::compare looks for the compatible score first.  So it's possible that 
the callers of that compare function simply use it in the wrong direction, 
or something like that.


Ciao,
Michael.
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx