Libzypp/Application Layer/Higher Level Objects

From openSUSE

Higher Level Objects: Patterns, Patches, Languages

Typically, a resolvable corresponds to a package. But there are also higher level objects in libzypp:

• Patterns (collections of packages to fulfil a certain task)
• Patches (updates to one or more packages)
• Languages (collection of packages to support a certain language: Translations, fonts, input methods, other localization packages)

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 packages that belong to them.

Other higher level objects include:

• Selections: Obsolete; similar to patterns, but much more simplistic
• Products
• Repositories
• RPM groups: No status for any RPM group, just for enumerating the matching packages

Operations on Higher Level Objects

• Enumerate (return iterator) the higher level objects of this kind
  • Enumerate patterns
  • Enumerate patches
  • Enumerate languages
  • Enumerate repositories
  • Enumerate RPM groups

• Enumerate (return iterator) the content (packages) that belong to one specific higher level object
  • Enumerate all packages that belong to a pattern (including those packages that belong to an invisible sub-pattern -- recursively)
  • Enumerate all packages that belong to a patch
  • Enumerate all packages that belong to a language
  • 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")

The last enumeration is new (as of 2007-10-23). This could be done by the app layer or by the libzypp back-end much more efficiently than by the UI. The UI has to iterate over all resolvables of all selectables in the pool, retrieve the RPM group field for each of them and (string-) compare it with the currently selected RPM group. This in turn triggers reading of all respective package meta data from the repositories or from the repository caches which is not really necessary for this operation.

Changing the Status of Higher Level Objects

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.

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.