http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c yang xiaoyu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xyyang@novell.com AssignedTo|bnc-team-screening@forge.pr |locilka@novell.com |ovo.novell.com | -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c2 Ján Kupec changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium CC| |jkupec@novell.com Summary|apparmor gets installed |patterns and/or their |even when pattern is |contents get installed even |tabooed at install |if the pattern is | |tabooed/locked --- Comment #2 from Ján Kupec 2010-04-01 09:11:35 UTC --- Thanx for the report! IIRC we do not have any special pattern locking handling. That means, even if the pattern objects is locked, you still can install the packages it 'contains', since package locks lock different objects. And if you install enough packages to satisfy the pattern's dependencies, it is then reported as installed... This is of course a bug. That said, i see three options: 1) either we disable the pattern locking in the UIs 2) or we add additional logic for adding pattern locks which would also put locks on the packages it contains 3) or we change zypp/satsolver to do this automatically when a pattern lock is encountered -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c4 Ján Kupec changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tgoettlicher@novell.com --- Comment #4 from Ján Kupec 2010-04-01 09:54:56 UTC --- (In reply to comment #3)

It is not "of course a bug". It's like saying "I locked package foo with requires bar, and now bar gets installed".

Sure, from the POV of the solver/zypp. But from the POV of the user more like "i locked a *pattern* but i still can install the packages it contains (surprise), and heck, after i install them, the pattern itself is shown as installed (even more surprise :O) => it's bug in the UI. I'm fine with 1), too. But if such feature will be demanded, maybe 3) will be the way to go. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c6 --- Comment #6 from Michael Schröder 2010-04-01 11:00:58 UTC --- #4: the problem is that we don't know exactly what a pattern "contains". -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c8 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mc@novell.com AssignedTo|zypp-maintainers@forge.prov |coolo@novell.com |o.novell.com | --- Comment #8 from Michael Andres 2010-04-01 13:36:02 UTC --- The curse of code11 pattern handling. I pass it to Coolo, as he broke it by introducing the patterns-openSUSE-* packages. By duplicating all dependencies on the package layer, one is still able to trigger installation of AA by selecting the pattern, but locking the pattern has no effect, as it does not affect the package layer. UI: pattern:base --recommends--> pattern:AppArmor | | requires requires v v Packages: patterns-openSUSE-base --recommends--> patterns-openSUSE-apparmor If we want a solution for 11.3 (and also future SLE) we should think about it ASAP. We could think about dropping patterns (also product) as primary solvable objects in the pool. Instead represent them as specialized packages. But that will also have some impact on zypper, pkgkit and the UIs. A probably cheaper solution is the same approach as we currently have for products. We let the pattern and the representing package share the same status (selecting the pattern in fact selects the packages). All dependencies must be expressed on the package level. As the objects would stay in the pool, there should be almost no impact on zypper, pkgkit and the UIs (but mls@ will sigh). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=592640 http://bugzilla.novell.com/show_bug.cgi?id=592640#c10 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FEATURE --- Comment #10 from Michael Andres 2010-04-26 13:14:08 CEST --- FATE#309385: We need to clearly define the way to deal with patterns -- Configure bugmail: http://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=592640 https://bugzilla.novell.com/show_bug.cgi?id=592640#c12 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net --- Comment #12 from Michael Andres 2011-03-02 12:20:25 CET --- *** Bug 663759 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=663759 -- 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.