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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Matz schrieb:

Hi,

On Mon, 11 Feb 2008, Michael Matz wrote:

...

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.

I think I know. The code in question looks like so:

if (uninstalled->arch().compare( provider->arch() ) < 0) // provider has "better" arch, take it

The data in question is, that uninstalled has arch i586, provider has x86_64. So, i586->compare(x86_64), which is (Arch::compare just calls the below):

int compare( const CompatEntry & rhs ) const { if ( _compatScore != rhs._compatScore ) return( _compatScore < rhs._compatScore ? -1 : 1 ); return _archStr.compare( rhs._archStr ); }

The _compatScore is the number of archs compatible with it. Hence i586->compatScore is three, and x86_64->compatScore is six. Hence -1 is returned.

This is sort of true in the sense that more archs are compatible with "x86_64" than there are with "i585" (six vs. three). But of course it's the completely wrong mean to determine if x86_64 can and should replace a i586 package. It simply makes no sense to use Arch::compare() as a "better" predicate on archs.

Ciao, Michael.

Hm, I cannot find this code. Is it in zypper ? Some days ago I have run some testcases and no archtecture change has been done. So I am little bit confused. Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Mon, 11 Feb 2008, Michael Matz wrote:

I've asked coolo to try the attached patch^Whack (it still wouldn't be completely correct, but at least it won't try to install incompatible candidates over already installed packages).

Although it doesn't help coolo (which is really strange, there must be still some other entity which also adds candidates :-( ), let's at least attach the thing I thought would help, perhaps it sparks some ideas. Ciao, Michael.

On Tue, Feb 12, Michael Matz wrote:

An idea it sparks is for example "carefully count parentheses in long conditions" :-) Here's a patch which actually works. It ignores all candidates which have an Arch incompatible with the Arch from the installed package. Theoretically that's too strict..

That's IMO wrong. You may prefer (policy) to keep the architecture of an installed package. But if you change the architecture, you most probably want the 'best' architecture available. Not something compatible to the installed one. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Tue, 12 Feb 2008, Klaus Kaempf wrote:

* Michael Andres [Feb 12. 2008 16:04]:

...

You may prefer (policy) to keep the architecture of an installed package. But if you change the architecture, you most probably want the 'best' architecture available.

Right, this is a policy which is currently defined as

- keep architecture during 'maintenance' updates - choose 'best' architecture during 'distribution' updates

But that 'best' architecture needs to be at least compatible with the system. That isn't checked anywhere. My hack checks the wrong thing (but conservatively correct) and I mentioned this. But that's only because I don't know how to retrieve the system Arch. If somebody tells me, I can change the lines to "candidate.arch().compatibleWidth (systemArch())" Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Tue, 12 Feb 2008, Klaus Kaempf wrote:

* Michael Matz [Feb 12. 2008 17:17]:

...

But that 'best' architecture needs to be at least compatible with the system. That isn't checked anywhere.

Well, thats bad. libzypp checked when parsing repository metadata and discarded solvables incompatible with the target system. repo_add_solv() could (should?) do this.

Yeah, this is what ma now implemented.

...

My hack checks the wrong thing (but conservatively correct) and I mentioned this. But that's only because I don't know how to retrieve the system Arch. If somebody tells me, I can change the lines to

"candidate.arch().compatibleWidth (systemArch())"

sat-solver shouldn't try to detect the architecture.

I was talking about libzypp code, specifically the current implementation of of distupgrade in Resolver::doUpgrade. That certainly should know the system architecture (or better it's compatibility set). The point is mood, though, since we're not seeing incompatible solvables anymore. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Fri, 15 Feb 2008, Michael Schroeder wrote:

On Tue, Feb 12, 2008 at 05:38:28PM +0100, Klaus Kaempf wrote:

...

Well, thats bad. libzypp checked when parsing repository metadata and discarded solvables incompatible with the target system. repo_add_solv() could (should?) do this.

No, it shouldn't.

Right now, ma implemented this by nulling out the solvables which are of incompatible architecture. I'm not totally excited about this, but it should work fine (and has the benefit that for applications using libzypp nothing changes, i.e. they don't see incompatible solvables). An alternative would have been annotating doUpgrade() (and everything else which tries to figure out update candidates on its own) with compatibleWith() checks, like I started to do. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Tue, Feb 12, Michael Matz wrote:

But that 'best' architecture needs to be at least compatible with the system. That isn't checked anywhere. My hack checks the wrong thing (but

The (zypp)pool does not contain any system incompatible arch. This is something the pool asserts, that's why no algorithm checks it. The sat-pool loads all architectures from the solv file, not just the desired ones. This broke some stuff. But it is now fixed. There are no more incomatible architectures in the pool. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org