Bug 381137

Summary: zypper dup tries to make architecture change for lots of x86_84 packages
Product: [openSUSE] openSUSE 11.0 Reporter: Markus Koßmann <markus.kossmann>
Component: libzyppAssignee: Jan Kupec <jkupec>
Status: RESOLVED FIXED QA Contact: Duncan Mac-Vicar <dmacvicar>
Severity: Major    
Priority: P5 - None CC: schubi
Version: Factory   
Target Milestone: ---   
Hardware: 64bit   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: output of "zypper dup"
zypper.log
created solver testcase

Description Markus Koßmann 2008-04-18 02:24:18 UTC
when running zypper dup on my factory x86_64 installation a lot of "reinstalled" packages were announced. I canceled the update and looked into
zypper.log. It seems "reinstallation" means replacing x86_64 packages by their i586 counterparts. Then I created a testcase with "zypper dup --debug-solver".
Comment 1 Markus Koßmann 2008-04-18 02:26:58 UTC
Created attachment 208797 [details]
output of "zypper dup"
Comment 2 Markus Koßmann 2008-04-18 02:28:08 UTC
Created attachment 208798 [details]
zypper.log
Comment 3 Markus Koßmann 2008-04-18 02:29:25 UTC
Created attachment 208799 [details]
created solver testcase
Comment 4 Jan Kupec 2008-04-21 10:24:34 UTC
Seems bug 381772 is related, if not duplicate.
Comment 5 Stefan Schubert 2008-04-23 14:19:53 UTC
Great, a bugreport which already includes a testcase WITHOUT asking for it ;-)
Comment 6 Stefan Schubert 2008-04-23 14:27:03 UTC
It is the force-resolve option. Otherwise you would get following error message:

Problem 1:
====================================
package libcurl4-32bit-7.18.1-6.x86_64 requires libcares.so.2, but none of the providers can be installed

- allow architecture change of libcares2-1.5.1-9.x86_64 to libcares2-1.5.1-9.i586
- allow architecture change of libcurl4-7.18.1-6.x86_64 to libcurl4-7.18.1-6.i586
- allow architecture change of curl-7.18.1-6.x86_64 to curl-7.18.1-6.i586
- allow architecture change of yast2-transfer-2.16.1-55.x86_64 to yast2-transfer-2.16.1-55.i586
- allow architecture change of xmoto-0.4.2-4.x86_64 to xmoto-0.4.2-4.i586
.....
....
...
..

Jano, I think you have already add the "third" option besides "j/n" to continue ?
Comment 7 Jan Kupec 2008-04-23 15:12:21 UTC
Not yet, i just prepared the prompt text for it so that translators can do their work :O) Comming soon.
Comment 8 Markus Koßmann 2008-04-24 05:14:59 UTC
Would it be possible, that the resolver messages make clear that the basic reason for that problem is the non-existant -32bit.x86_64.rpm for libcares.so.2, which is required by  libcurl4-32bit ? 
Or is this allready done by the new prompt text ?
Comment 9 Stefan Schubert 2008-04-25 07:30:04 UTC
*** Bug 377346 has been marked as a duplicate of this bug. ***
Comment 10 Jan Kupec 2008-04-26 14:28:20 UTC
Done, the 'p' option will be shown whenever there will be something to remove after install --force-resolution (the default) was used. For all other cases, --no-force-resolution is used by default.

to be in zypper 0.11.1

(In reply to comment #8 from Markus Koßmann)
> Would it be possible, that the resolver messages make clear that the basic
> reason for that problem is the non-existant -32bit.x86_64.rpm for
> libcares.so.2, which is required by  libcurl4-32bit ? 
> Or is this allready done by the new prompt text ?

You will see what you would see if you used --no-force-resolution option.

package libcurl4-32bit-7.18.1-6.x86_64 requires libcares.so.2, but none of the
providers can be installed
Comment 11 Jan Kupec 2008-04-26 14:29:54 UTC
(In reply to comment #6 from Stefan Schubert)
> It is the force-resolve option. Otherwise you would get following error
> message:
> 
> Problem 1:
> ====================================
> package libcurl4-32bit-7.18.1-6.x86_64 requires libcares.so.2, but none of the
> providers can be installed

This is weird, 'dup' uses --no-force-resolution by default...
Comment 12 Jan Kupec 2008-04-26 14:30:47 UTC
Nevertheless, i will close this bug anyway, please retest on beta2 and reopen if the problem reappears.
Comment 13 Jan Kupec 2008-04-27 22:30:21 UTC
submitted