https://bugzilla.novell.com/show_bug.cgi?id=811899 https://bugzilla.novell.com/show_bug.cgi?id=811899#c1 Jiří Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsuchome@suse.com AssignedTo|jsuchome@suse.com |rhafer@suse.com --- Comment #1 from Jiří Suchomel 2013-03-27 13:12:57 UTC --- (In reply to comment #0)

The problem patches are openSUSE-2013-189-1 (sssd) and openSUSE-2013-235-1 (nss_ldap). I don't know what's wrong with them.

Maybe those packages have dependencies set incorrectly? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=811899 https://bugzilla.novell.com/show_bug.cgi?id=811899#c3 --- Comment #3 from Ralf Haferkamp 2013-03-28 10:19:06 CET --- Is glibc-32bit installed on your system? If yes, that would be the answer why all those package are getting installed. nss_ldap-32bit, sssd-32bit and most of the other -32bit bit variants of the pam_ and nss_ packages have this in there dependencies: supplements "packageand(nss_ldap:glibc-<targettype>)" Which means that they will be automatically installed when nss_ldap (or the specific base package) and glibc-32bit are installed on the system. Unless you set --no-recommends on the zypper commandline. This is the desired behaviour, see bug#354164 for details. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=811899 https://bugzilla.novell.com/show_bug.cgi?id=811899#c5 --- Comment #5 from Michael Catanzaro 2013-03-28 22:59:15 UTC --- Also any ideas on how to "contain the damage" from these updates, maybe withdraw/obsolete them or something so they don't affect people who haven't already run them? We don't want users to have to manually uncheck patches at each update just to avoid installing e.g. systemd-32bit. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=811899 https://bugzilla.novell.com/show_bug.cgi?id=811899#c7 Ralf Haferkamp changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rhafer@suse.com AssignedTo|rhafer@suse.com |coolo@suse.com --- Comment #7 from Ralf Haferkamp 2013-04-04 09:21:53 CEST --- (In reply to comment #4)

Created an attachment (id=532496) --> (http://bugzilla.novell.com/attachment.cgi?id=532496) [details] solver testcase

Yes, glibc-32bit is on the default install. Ok, then the installation of sssd-32bit is no bug, but the desired behaviour (at least it was in the past).

Anyone know why? I guess coolo can answer that. (re-assigning to him)

linux@linux:~> rpm -q --whatrequires glibc-32bit no package requires glibc-32bit That is not a valid test case. It just means that no package requires the package directly by it name. There might still be packages that require the other symbols that glibc-32bit provides. Try "rpm -e glibc-32bit" that should give you a list of packages that depend on other "provides" of the glibc-32bit package.

Will it be part of the default install if it's just recommended by another package? (Surely it's not in any of the default patterns?)

Solver attached just in case it's still useful.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=811899 https://bugzilla.novell.com/show_bug.cgi?id=811899#c9 Michael Catanzaro changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #9 from Michael Catanzaro 2013-04-06 18:12:41 UTC --- Ralf, Stephan, thanks for your help! The rpm -e trick is sweet, and enabling grub1 seems fair. But I'm still concerned about this for a couple of reasons: (1) I think our PackageKit backend ought to do the equivalent of --no-recommends when installing updates. (2) Wouldn't it be better to take care of supplements during the installation? (Correct me if I'm wrong, but this is already what we do for recommends, right?) (3) Are we really OK with recommending this huge amount of 32-bit libs on all 64-bit systems? E.g. systemd-32bit seems a bit excessive... if all this stuff is really needed, surely it should be not be handled postinstall? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.