Libzypp/Refactoring/Commit

From openSUSE

Commit requirements

Extensible strategies both for PoolItem and Pool

This means the program should be able to create a commit strategy based on Pool strategies (how to iterate the items, order, filtering multiple items) and strategies based on individual PoolItems (like logging each one, installing it, insert a log into the transaction log for rollback).

Testeable

Commit should be usable without any ZYpp static context.

with Extensible strategies the following features should be easy to implement:

• Commit that only downloads to a directory
• Commit that logs in a file or a journal for rollback

Use cases

• download all files and then install them
• download one by one, and install them going to the package history
• download and install, and then check for services running on unexisting files and callback to the user.

Analysis of the current code

The current code consist in different blocks of functionality.

Commit loop

Iterates over all pool items and calls the action(s).

Commit action

Receives a poolitem and does something with it

• has: infrastructure, for example the current commit code creates a RepoProvidePackage and it is kept during the whole loop.
• input: list of items
• output: some action over the item

Examples

• the current code (install, remove, delete)
• logging
• fake commit (for testcases)
• package history

Commit hooks

• input: commit list, root path
• output: some action over the system

Examples

• Set requested locales (pre commit)
• Apply weak and hard locks (pre commit)
• Post commit script runner
• Pre commit message runner
• FATE #300763: Warn about services using old libraries
  • In this case, the hook will be executing the command after commit and report to the generic message interface.

Architecture