Bug 592640

Created attachment 351665 [details]
yast2 logs after install

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

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

That being said, I'd go with option 1).

(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.

While it would be good to implement pattern taboo in libzypp, I think the real
problem in my case (apparmor) is whoever else (packages, other pattern?) pulls
in these AA packages in the first place even when the top level AA pattern
is not selected.  They shouldn't do that. AA should be only controlled by
that pattern or a user explicitely selecting these packages.
 
So most likely it needs some changes to dependencies or selections elsewhere.

#4: the problem is that we don't know exactly what a pattern "contains".

AA is AFAIK recommended by patterns base and enhanced_base. That's probably the reason why almost everyone gets it.

Libzypp knows about the pattern content, so I could translate a taboo pattern into weak locks on the contained packages. Thet one would get those packages only if they are actually required.

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).

I did not break anything any sane person would understand. I strongly suggest to remove all pattern "logic" as it was never reasonably implemented.

FATE#309385: We need to clearly define the way to deal with patterns

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

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