Libzypp NG/Implementation

From openSUSE

Libzypp NG Implementation Proposals

See also the refactoring proposal for the actual development.

Split parse, solve, and commit

• Factor out all repository handling
  • Parse repository data to a central (sqlite3) database
  • Let the solver operate on that database
  • Solver gets transactions, solves them, and returns (extended) transactions
  • Commit executes transactions

• Separate repository management
  • Split repository and package management
  • Into different libraries
  • Repository Manager supports add/edit/refresh/disable/remove
  • Repositories have a name, a url, a priority, and more

• Repository handling
  • Repository types (repomd, yast, etc.) are plugins to a repository manager
  • Download metadata to raw-cache directory
  • Asynchronous refresh (independant from applications)

• Central database
  • Contains repositories, resolvables, locks, transactions, policies, locales
  • Contains all information for solving and committing
  • Is an API
  • Writing can be slow and costly
    • Do lots of preprocessing
    • All parsing here
    • Maybe built complete dependency (provider - requirer relations) graph in helper tables
    • Solver can cache dependency query results and write them to these helper tables
  • Reading must be fast and cheap
    • Only minimal checks
    • No parsing
  • Needs consistency checking tools (aka fsck)
  • Can be regenerated from raw-cache

• ToDo's
  • Define SQL schema
    • Look at access patterns (solver queries, applications), make them fast
    • Look at zmd and yum sqlite schemas
  • Define new dependencies (conditional, expressions, etc.)
  • Define query abstraction layer
  • Define policy abstraction layer
  • Define transaction abstraction layer