Mailinglist Archive: opensuse-bugs (16417 mails)

< Previous Next >
[Bug 437162] Games Pattern is Checked even though no games are installed
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Fri, 14 Nov 2008 07:11:09 -0700 (MST)
  • Message-id: <20081114141109.0EA09CC7D2@xxxxxxxxxxxxxxxxxxxxxx>

User jkupec@xxxxxxxxxx added comment

Ján Kupec <jkupec@xxxxxxxxxx> changed:

What |Removed |Added
|visnov@xxxxxxxxxx, coolo@xxxxxxxxxx

--- Comment #9 from Ján Kupec <jkupec@xxxxxxxxxx> 2008-11-14 07:11:08 MST ---
It seems the main problem is that we do not have the desired behavior/policy

In this case, the pattern only requires a package that is likely to be already
marked/installed by another pattern (x11) => The pattern is evaluated as
installed (?) even though none of its 'contents' are actually marked/installed
(and the pattern itself is not marked for installation!).

How to handle this case?

There is nothing wrong from the solver POV with status quo, except that it is
not usable by the UIs without further definition of pattern handling. Let's

IMO we should evaluate patterns differently than packages in the UIs:

* we should present a pattern to the user as installed IFF all of its
_requires+recommends_ are installed/satisfied. We should provide a method
for this in libzypp.
* marking a non-installed pattern for installation should result
in installation of requires+recommends. This works, AFAICS, unless
onlyrequires = 1 (i don't know wheter GUIs set this flag somewhere).
But it should work like this for patterns regardless of this flag!
* marking a satisfied pattern for installation should result in installation
of all of its not-yet-installed recommends. This shoud ideally done in the
solver (special handling for patterns). But it can be done also
in the UI layer of libzypp.
* methods for marking/removing pattern's suggests would be nice as well
* deleting a pattern would mean deleting all of its 'contents'.
* deleting a package recommended by the pattern would render it 'not installed'
but it would not remove any other packages of the pattern.

So in the end, it could all be handled like this in the solver, not much to do
in the UIs (just some interface to the 'install/remove all pattern's suggests'
functionality). But whether we do this in UIs, libzypp, or the solver itself
does not matter. First we need to agree on how to handle patterns.

Any conceptual problem with this solution? Something missing?

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.
< Previous Next >