Libzypp/Application Layer/Filter Views and Queries

From openSUSE

Filter Views and Queries

Current filter views in the package selectors include:

• Patterns
• RPM Groups
• Languages
• Repositories
• Search
• Installation Summary
• Patches
• Update Problems
• All Packages
• Automatic Changes
• Products

The filter views for Patterns, Patches, Languages and RPM Groups are implemented using the enumerations explained above.

Repositories Filter View

This adds a second layer of filtering over those views:

• All Packages
• RPM Groups
• Search
• Installation Summary

In each of those sub-filters the UI shows only those packages that are available from one of the currently selected repositories. This kind of filtering is currently done on the UI level.

Q: Can any performance or memory benefit be expected from changing this?

Filter Views Based on Selectable Status

These filter views displays all selectables that have certain selectable states set. The combination of states is either defined by the user or set by UI.

Installation Summary Filter View

The most common use of this filter is to display all pending transactions (this combination of selectable states is preselected by default) i.e. all packages marked for installation/update/delete + all locked packages. But as the subset of selectable states can be changed by user,it can also be used to display:

• All packages that won't change
• All packages that will be updated
• All packages that are currently installed
• ...

Currently, the UI iterates over all package selectables and checks their respective selectable status against those the user wants to see.

Q: Can any performance or memory benefit be expected from changing this?

Automatic Changes Filter View

This is very similar to the installation summary filter view, but it has the "Auto" states (Auto-Install, Auto-Update, Auto-Delete) preselected.

Searching (Query)

Searching is currently done entirely in the UI, with serious impact on performance now that the latest libzypp versions no longer load all package meta data into memory upon startup. Using the search facility now will trigger reading those meta data as each resolvable is checked against the search criteria. This should definitely be moved into the app layer.

zypper already has a quite powerful query mechanism. It would proably make a lot of sense to move it into the app layer or even into libzypp itself.

The package selectors currently support searching in any combination of those fields:

• Package name
• Package summary
• Package description
• RPM Provides
• RPM Requires

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.

A draft proposal for such an API can be found here (the draft lacks support for the selectables and queries by provides/requires). Please follow that thread for further discussion.

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.

Patch Categories Filter View

This filter view enumerates the patches that belong to one of patch categories (or enumerates all patches). These categories are:

• Installable Patches (needed + broken + satisfied, but not yet installed)
• Installed and Installable Patches (the same as above + already installed)
• Update Stack Patches (affecting libzypp)

There are also other criteria for filtering patches (ncurses UI already implements some of them), such as:

• Security Patches
• Recommended Patches
• Optional Patches

All Packages

This filter view is currently only used in connection with the repositories filter view. It enumerates all selectables in the pool. The repositories filter view filters out those that also match the selected repositories.

Products

This filter view lists all available products. Currently, it does not try to list a a product's content. This might be difficult, too, since a product might be any combination of patterns, packages and maybe even patches.