Bug 230685

It seems to be an accident that the x86-64 package is in the ftp instsource and in the security updates. But it shouldn't be a critical one.

It seems that the 32bit package is installed by default on any system if chosen for installation. (If that isn't the case please report in installer component)

An online update has to keep the same arch package for applying updates so nobody should see the x86-64 package because of the online update. If this is not true and ZMD breaks with it it has to be fixed for ZMD in the respective component.
Anyway at least it's never component Firefox and it shouldn't be a problem to have the packages out there since they shouldn't be used if the user actively choose it.

A separate report about zmd already exists: bug 230687, currently waiting for logfiles. Note that in the theoretical case that it would be fixed in zmd, zmd might not be able to update itself because 1 broken dependency tends to block zmd from updating anything. Maybe the "install package manager updates first" thing works now, but last time I checked, it did not.

Last time I had access to x86_64 hardware, the "keep the same arch" thing did _not_ work with yast2 online_update, it happily updated i586 packages to x86_64. Unfortunately I cannot test this now, maybe it works.

Besides that, many users are not using yast2 and/or zmd any more these days, so you will get support requests about not working plugins and/or beagle extensions in any case, but you could declare them "invalid/worksforme because of using an unsupported package manager". However, this will be difficult to communicate because in previous cases where other package managers broke the system, it was because of their habit to install i586 packages on x86_64 systems. Now it's the other way round.

There is also the case that MozillaFirefox might not be installed at all and the user selects it for installation, in that case YaST will pick what it thinks is the "better" arch: x86_64. So, the presence of an x86_64 MozillaFirefox really indicates that it is supported. But this case had been broken even before the online update...

I really don't know what to do about this report. => "Other"

OK, confirmed a problem now:
Installation of Firefox is 32bit for me at least, but I get a conflict immediately if I try an online update with YOU:
"Installation von MozillaFirefox-translations-2.0.0.1-0.1.x86_64[SUSE-Linux-10.2-Updates] nicht möglich
    MozillaFirefox-translations-2.0.0.1-0.1.x86_64[SUSE-Linux-10.2-Updates] kann nicht installiert werden, da MozillaFirefox-translations-2.0.0.1-0.1.i586[SUSE-Linux-10.2-Updates] bereits für die Installation gekennzeichnet ist"

I don't know why that happens. Seems like a bug in libzypp.

Please generate a solver testcase described here:

http://en.opensuse.org/Bugs/YaST#I_want_to_report_a_bug_related_to_package_dependencies_and_libzypp_solver._Which_logs_to_attach.3F

Created attachment 111825 [details]
testcase logs

*** Bug 232413 has been marked as a duplicate of this bug. ***

firefox has the problem that
it both provides and obsoletes MozillaFirebird.

OK, I can reproduce it:
SuSE-Linux-10_2-Branch/libzypp/testsuite/solver/data.deptestomatic/bugzilla-tests/bug230685-test.xml

Has been fixed:
update packages: changing architecture is only valid while an
system update and NOT while an update via a patch.

Thank you.

Added Anja for coordination.

Created attachment 113014 [details]
list of rpms updated after updating libzypp

Created attachment 113015 [details]
UI of yast2 indicating dependency problems

Heiko, please attach a generated Testcase described here:
http://en.opensuse.org/Bugs/YaST#I_want_to_report_a_bug_related_to_package_dependencies_and_libzypp_solver._Which_logs_to_attach.3F

Created attachment 113111 [details]
YaST2 log from resolver test

Bug #230687 seems to be a duplicate of this one.

You have disabled the you source:
Source[4|YUM|20061219-175249]{http://you.suse.de/pub/suse/update/10.2/(/); cache /var/lib/zypp/cache/Source.RfcOOz; autorefresh: 1; enabled: 0}

So you are getting an incomplete libzypp patch cause the atom libzyy has not been installed:

2007-01-16 15:53:39 <999> waerden(25624) [solver] ResolverContext.cc(requirementIsMet):1519 ResolverContext::requirementIsMet([atom] (namedcap) libzypp == 2.11.2-2.1) N
2007-01-16 15:53:39 <999> waerden(25624) [solver] QueueItemEstablish.cc(process):240 Atom/Patch/Installed/Establishing I__s_[S1:0][patch]libzypp-2460-0.noarch has unfulfilled requirement [atom] (namedcap) libzypp == 2.11.2-2.1 -> incomplete

I cannot see the reasons why the atom has not been installed before. But it cannot be reinstalled cause it is not available anymore. Thats why you are noot see any package which belongs to the patch in the UI.

Please add the source and try again.

Created attachment 113144 [details]
YaST2 log from resolver test

Thanks Heiko.
After adding you again the not installed atom  is satisfied:

ResolverContext::itemIsPresent(<US_s_>U__s_[S5:0][atom]libzypp-2.11.2-2.1.i586) Y
ResolverContext::requirementIsMet([atom] (namedcap) libzypp == 2.11.2-2.1) Y
all requirements of I__s_[S1:0][patch]libzypp-2460-0.noarch met -> satisfied

So the patch is satisfied too and will not be installed again.

I have tested with a new installation again and the atoms has been installed correctly. So I cannot reproduce it. It does not matter cause this error would be handled by the solver automatically as long as the source is available.
I would like to close this bug again if noone has an objection.

released

Will this also be fixed in 10.1? Upgrading to Firefox 2 is currently broken because of this bug.

Sorry, the fix does not fit for every case (only 50%). 
We will need an additional fix;-(

*** Bug 238182 has been marked as a duplicate of this bug. ***

Patchinfo created. Packages submitted.
Thanks !!!!

*** Bug 239199 has been marked as a duplicate of this bug. ***

*** Bug 239199 has been marked as a duplicate of this bug. ***

released

*** Bug 230687 has been marked as a duplicate of this bug. ***