* Duncan Mac-Vicar P.
I would like others (especially Michael) to review it.
I am quoting the blocks of texts from the Wiki, which I would like to focus the discussion on.
I took the freedom of extending the application layer pages in the wiki with - tagging them with Category:Libzypp - pointing out that there are more consumers of libzypp than just UIs (i.e. bindings to common scripting languages) - questioning the semantics of a 'candidate' - pluraling 'installed package'
The app layer also keeps track of the candidate. This is important when the selectable status is used since some operations (install, update) implicitly operate on the candidate.
It should be clearly noted that the current notion of a 'candidate' is misleading and cannot be fulfilled (in each case) by the solver. Based on this, the selectable structure mypkg selectable * mypkg-12.3-42 resolvable from openSUSE DVD1 * mypkg-12.3-47 resolvable from openSUSE update server * mypkg-12.3-47 resolvable from gwdg.de mirror server * mypkg-12.3-42 resolvable from RPM DB (already installed) * mypkg-12.4-3 resolvable from Packman server should rather be mypkg * 12.3-42 installed * 12.3-42 available from openSUSE DVD1 * 12.3-47 available from openSUSE update server, gwdg.de mirror server * 12.4-3 available from Packman server Operations should always be performed on the root of this 'tree', namely 'mypkg' (without a specific version or repository). Choosing a specific version (eventually from a specific repo) should be the exception, because it might lead to - package not being installable (because of missing/breaking deps) - more package updates being triggered (because of changed deps)
Patterns (collections of packages to fulfil a certain task)
This is where the UI <-> library problems starts. What the wiki describes there is the description of a Selection.
Technically, none of those higher level objects has a package content: They all just have dependencies that typically (but not necessarily) are satisfied by packages.
This is going to change in 11.0, patterns and patches will have 'package content'.
Changing the status of a pattern, patch, or language typically affects the status of other resolvables, most notably the packages that belong to this pattern, patch, or language. Those changes should be propagated immediately to those packages so the user can instantly see the effect.
I question the need for immediate propagation, at least in a 'fully resolved' way[1][2]. Choosing a pattern 'for installation' should be treated as a macro call, resulting in all 'contained' packages (app layer will provide an interator) to be choosen 'for installation'. IMHO, this should be sufficient to match the user expectation. Klaus [1] Full resolution on a package level. [2] Resolution of pattern<->pattern dependencies should still be done. --- 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