Communication between the YCP application and the C++ package selector widgets is very limited (almost nonexistent). In particular, the YCP application cannot create a pool and pass a handle to that pool to the C++
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. package selector or vice versa.
Thus, for all important objects like pool or similar, there must be a singleton object for each that can easily be accessed from both the YCP code (via package bindings) and from the package selectors. Those singleton objects should live in the app layer.
Selectables have a higher level status that is the result of the useful permutations of the status flags of their resolvables and the fact whether or not one resolvable from this selectable (one instance of that package) is already installed:
Matching Selectable and Resolvable Status and Candidate Handling The package selectors use the selectable status. They never store any selectable's status; they always retrieve the status when it is needed. When the user changes a selectable's status, they set new status and retrieve it for display so the display and the selectable status are always in sync. Since selectable don't exist in the libzypp layer, matching a selectable status to the individual resolvable status flags is done by the app layer and vice versa. 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.
I think this is one of the central parts of the problem we need to solve.
As long as the user did not explicitly choose a specific candidate, the app layer automatically chooses one from the available resolvables. That automatic choice takes matching architectures and most recent version number into account.
This is not trivial. Right now the UIs do this choices in some random code somewhere in the UI, or using the selectable candidate function, which is now incomplete. This kind of decision is the same as the solver local policy. So we have to connect them trough the API somehow. Imagine this something like: bestCandidate( list_of_candidates, task ) Of course this has to be in Selectable, but it has to be connected to the local policy, and it depends on the task you want to execute. Otherwise the UIs will continue breaking things like vendor (the UIs iterate over a package list and select the higher version instead of the best candidate according to the system policies ).
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.
From a user's point of view, however, those higher level objects are nothing else than containers for packages. Though this is a somewhat simplistic view, users typically want to see what is behind a pattern, a patch, or a language resolvable. This is why each of them should have a mechanism to enumerate the
Exactly. packages that belong to them. This is true, but only if you can live with the true: the mechanism to enumerate the list of packages is just an algorithm, not a list. It can be false information. That is why I tried to start using the term "related packages" instead of "content".
Enumerate all packages that belong to an RPM group (not just for leaf RPM groups, also those that belong to a higher level like "Productivity")
Changing the status of a pattern, patch, or language typically affects the status of other resolvables, most notably the packages that belong to this
I think the best way to solve this problems is to introduce categories for all resolvabes (tags), in the case of packages it can be implemented using rpm groups, and implement iterators to match full tag, part of it, a collection of them, etc. pattern, patch, or language. Those changes should be propagated immediately to those packages so the user can instantly see the effect.
In the past there were calls to just propagate those changes, which worked in most cases, but not in certain pathological ones. But those calls were quick, so for the user there was an instant response. Recent changes rely on a full solver run to propagate the changes, which gives the correct result in all cases, but which on the other hand is much slower. As some users disable the automatic dependency check because of this, some of them get confused because no change is propagated. There have been bug reports with lively discussions about that.
I read this as, we need to do a solver run without doing a solver run? This is a technical limitation, which could be solved of we could for example cheap-ly clone a pool , do something and see the changes, without making the main one dirty. I have no idea yet if that undocumented dirpool has something to do with that ;-)
The user can select any one of those search modes:
* Contains * Begins with * Exact match * Use wildcards (*, ?) * Use regular expression
Case sensitivity in all searches can be switched on or off.
A query engine to replace this functionality in the UI should enumerate (return an iterator to) the selectables that match the given criteria.
Update Problems Filter View This filter view enumerates those packages that for one reason or the other could not automatically be updated during a system update. Adding packages to this list is done by the system update application layer.
And what is the criteria for searching those?
Libzypp/Application Layer/API Proposal
enum Type { PACKAGE, PATTERN, PATCH, LANGUAGE }
Why resolvable kind can't be used here? Why the need to duplicate it?
* Create pool iterator (based on the above query as a parameter)
Pool pool = new Pool (q);
So this is like a pool proxy based on a query? Why not the iterator taking the query as a parameter (Michael could comment more?) I have one concern with the design of the pool based on queries. It means we have to load the pool data, this will not be bad with the sat solver, but this is not the same zypper does, as zypper only gets the resolvable data to be displayed on the screen, without any pool. Appart of that the query api seems fine. Other API that could be part of the zypp layer is a command oriented api. If you look what API smart offers to the UIs is a much simpler API, and it is the same the command line tool offers, and this is quite similar to all zypper code. It defines a Command class (install, search, etc) it defines a abstract interface for callbacks (confirm dialogs, progress, questions, etc) The UI simply creates a command and executes it. This is a much simpler approach, but I think it is needed in addition to the layer our selector need. Both packagekit and any app wanting to install a package could benefit from this. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org