* Stanislav Visnovsky [Feb 27. 2008 12:44]:

...

- Currently there is no functionality when a pattern will be "deleted". Is this still an valid user input in the UI due the fact that we do not install patterns anymore ?

I believe so. At least, we would need to adapt UI to avoid checkbox next to pattern.

Patterns should be handled as macros. Installing a pattern selects all 'contained' packages for installation. Removing a pattern selects all 'contained' packages for removal. I believe this is the easiest way to make 'install' and 'remove' semantics of patterns transparent to users. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Schroeder napsal(a):

On Wed, Feb 27, 2008 at 12:52:46PM +0100, Klaus Kaempf wrote:

...

Removing a pattern selects all 'contained' packages for removal.

What if a package is in more than one pattern?

A package might be even recommended by pattern A and requested by pattern B. In case of deleting the pattern A ... A bit tricky, isn't it :)? Of course, solver would add the package again I guess ... I hope ... L.

Klaus Kaempf napsal(a):

* Lukas Ocilka [Feb 27. 2008 13:14]:

...

...

...

Removing a pattern selects all 'contained' packages for removal. A package might be even recommended by pattern A and requested by

On Wed, Feb 27, 2008 at 12:52:46PM +0100, Klaus Kaempf wrote: pattern B. In case of deleting the pattern A ...

A bit tricky, isn't it :)? Of course, solver would add the package again I guess ... I hope ...

Yes, its tricky ;-) The main question is: What would users expect and how can we apply the 'principle of least surprise' ?

Suggestions welcome ...

Maybe we should start with questions: * Why could user want to remove a pattern at all? * How are patterns currently designed? What they contain? * Are there packages that are not in any pattern but installed automatically by solver (libraries, for instance)? (similar to the previous question). We should imagine the situation when user wants to remove something (pattern, language) and imagine what makes him do it. Then we can understand and design the workflow better. L.

Stephan Kulow napsal(a):

...

Maybe we should start with questions: * Why could user want to remove a pattern at all? Because they want to save room and don't care for "Games". Or they tried "KDE" and figured it has nothing to do with

Am Mittwoch 27 Februar 2008 schrieb Lukas Ocilka: the Kentucky Deparetment of Education.

Hmm, yes, removing unneeded software unintentionally installed (by mistake or by confusing pattern name, for instance) is a valid use case. In this case, user probably wants to have the system in the same state as he had it BEFORE installing that pattern. If a package was installed before, he probably wants to have it installed after removing the pattern. Example ------- (before): * had installed "Multimedia" pattern with "Amarok" (installation) * selected "KDE" pattern and installed (removing) * unselected "KDE" pattern and removed; unfortunately both "KDE" and "Multimedia" patterns contain "Amarok" :( - removed (new state) * have installed "Multimedia" pattern (?) but somehow incomplete because of the missing Amarok. And yes, I know that users keep complaining that they can't remove some package because solver keeps adding it by some dependencies. Maybe we could try to remove those dependencies too ...?

...

* How are patterns currently designed? What they contain? They are grouping functionality by toplevel dependencies. It's more likely that a package is only in pattern, even though it's far from a rule.

In this case, we can't remove the package automatically if it is in more patterns.

...

* Are there packages that are not in any pattern but installed automatically by solver (libraries, for instance)? (similar to the previous question). Roughly 15% packages of a full install are not listed in any pattern. Language dependencies, hardware specifics or libraries.

Hard to say whether it is enough or too much :) But as a number it looks pretty :)

...

We should imagine the situation when user wants to remove something (pattern, language) and imagine what makes him do it. Then we can understand and design the workflow better. Well, if Joe deletes "Office" functionality, he no longer cares for attachments sent by his mother, so he doesn't want to have no ooimpress blocking him from saving ripped CDs :)

Poor mother if Joe ignores her attachments ;) L. -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- Ano, ano. Moudry rozkaz. Sam jsem nemel v tech gratulacich jasno.

On Wed, Feb 27, Klaus Kaempf wrote:

* Lukas Ocilka [Feb 27. 2008 13:14]:

...

...

On Wed, Feb 27, 2008 at 12:52:46PM +0100, Klaus Kaempf wrote:

...

Removing a pattern selects all 'contained' packages for removal.

1st I would not call it 'remove a pattern' because we don't install one. Maybe 'cleanup'.

...

A package might be even recommended by pattern A and requested by pattern B. In case of deleting the pattern A ...

a) Pattern B is selected: It's requirements are active, and the package stays. b) Pattern B is not selected: There's no requirement from Pattern B. If the solver can handle a 'weak delete request', the package should be deleted unless some package or selected pattern recommends/requires it.

...

A bit tricky, isn't it :)? Of course, solver would add the package again I guess ... I hope ...

Yes, its tricky ;-) The main question is: What would users expect and how can we apply the 'principle of least surprise' ?

If a pattern is sort install macro, it's requirements/recommends to packages/patterns are active, iff the pattern is selected. After commit the pattern is no longer active. It has no requirements, no purpose. But it still is a container of packages. AFAIK we even want to compute some value telling how many % of the patterns content are installed. Cleaning the pattern would then issue a 'weak delete request' for each package included in this pattern. The packages are deleted, unless required/recommended by other packages or selected patterns. If we want/need more protection, we had to 'auto'-select patterns, because only selected patterns recommend/require packages. - Offer a way to let the user 'autoselect' patterns (same as install but using a different name). - Define (or let the user define) a threshold, and 'auto'-select patterns which are more than X% installed. What we IMO should not do, is deleting more packages than we list/display as pattern-content. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Wed, Feb 27, Lukas Ocilka wrote:

...

What we IMO should not do, is deleting more packages than we list/display as pattern-content.

But Coolo said that roughly 15% of packages are not in any pattern which can produce backward dependencies if we don't delete them too (if they

I'm not shure if cleaning all patterns must result in an empty system. - You clean the pattern some packages may stay because they are required from somewhere else. But you won't loose more then you see in list. No unexpected package loss. - You know what you do and want to get rid of all of them, then file a delete request (as user) for all packages in the list, and resolve all solver problems by removing the installed package. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

* Michael Andres [Feb 27. 2008 15:21]:

On Wed, Feb 27, Klaus Kaempf wrote:

...

* Lukas Ocilka [Feb 27. 2008 13:14]:

...

...

On Wed, Feb 27, 2008 at 12:52:46PM +0100, Klaus Kaempf wrote:

...

Removing a pattern selects all 'contained' packages for removal.

1st I would not call it 'remove a pattern' because we don't install one. Maybe 'cleanup'.

Hmm, from a users perspective, choosing a pattern for 'installation' isn't different from choosing a package for installation. And the user will expect to be able to 'remove' a pattern. So although we'll change the internal semantics, the user shouldn't bothered with implementation details. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Stefan Schubert wrote:

- Currently there is no functionality when a pattern will be "deleted". Is this still an valid user input in the UI due the fact that we do not install patterns anymore ?

Hmm, an interesting thread also for zypper {info,lu,up,se,...} -t {pattern, product} (i guess it applies also to product(?)) :O) This very much changes the way how lu and up works (e.g. zypper lu -t pattern doesn't work now). Let's provide the functionality through a libzypp API: - determine whether a pattern/product is installed - get pattern/product 'contents' (already listed in the app layer requirements) - determine whether there is an update available for pattern (solver algorithm) But we won't be able to tell whether a pattern/product is installed without repositories (target only) anymore. Is that OK? jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org