Libzypp/Application Layer/Selectables

From openSUSE

Selectables

Selectables are objects that each group a number of resolvables that might come in several instances (typically one from each repository):

• 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

As the number of repositories is dramatically increasing with more and more community members using the openSUSE build service, it becomes more and more important to not clutter user interfaces with all instances of a package. The above example is not exagerrated; it is becoming more and more common to have many instances of the same package in various locations.

When a user wants to install a package, usually he wants the best one available from any of his active repositories. Sorting out where it comes from is not something most users want to be bothered with. Users tend to see packages on the selectable level, not the various instances (resolvables).

The existing package selectors by default show data for two instances of a selectable:

• The candidate: The "best pick", usually the most recent instance; this is the package that will be installed if the user changes the status of this selectable to "install" or "update".

• The installed packages, if any instances of this selectable are installed.

Remark: Installing the most recent package might result in additional package updates in order to fulfill dependencies. This might not be in the users interest. Choosing a specific(!) candidate is not straightforward.

Remark2: There might be multiple versions of a package installed in parallel. This is especially true for kernel packages.

Selectable Status vs. Resolvable Status

Resolvable Status

Resolvables have a low level status (the transaction status):

• no change
• install
• delete

In addition to that, they also have a "locked" flag:

• locked
• unlocked

And they keep track who caused a status change:

• user
• application (dependency resolver)

Selectable Status

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:

"Install" and "Keep" might be overridden by the dependency solver to satisfy dependencies. This includes selecting a higher level object like a pattern, a patch or a language: Their respective content is specified via dependencies.

Most users tend to think in terms of "update this package", not "uninstall the old version and install a newer version". This is why the selectable status was chosen for the package selectors rather than the individual transaction states, the lock flags and the auto-flags.

Also, since not all combinations of those flags are legal, it makes sense to reduce the matrix of all possible permutations to those that are.

This imposes some restrictions: Using only the selectable status, it is not possible to install multiple instances of the same selectable in parallel. While for most packages this is not a real life restriction, there are some few notable examples: Kernel and kernel module packages. Most other packages would have file conflicts anyway.

Remark: Given the new packaging guidelines for shared libraries, different versions won't have file conflicts any more.

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.

The UI changes the candidate only upon explicit user request, in which case that user request has absolute priority over anything selected automatically by the dependency resolver.

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.

Other Selectable Operations

• Return installed resolvables (if there are any)
• Return candidate resolvable (if there is any)
• Enumerate all resolvables that belong to the selectable (return iterator)

• Store and return information whether or not the user already accepted a license agreement for this selectable (if it has any) during this program run