Mailinglist Archive: zypp-devel (230 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar P. <dmacvicar@xxxxxxx> [Jan 27. 2008 14:14]:
> 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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx