Libzypp NG

From openSUSE

Libzypp -- Next Generation

This page is intended as a discussion platform for developers interested in package management.

It explicitly does not make any promises to fix mentioned bugs, provide discussed requirements, or actually implement any of the proposed solutions.

Known problems

- the order does not indicate importance -

• Speed
• Memory consumption
• Inconvenient APIs
• Refactoring needed
  esp. implementation of sources
• Mixed semantics
  e.g. Source init and referesh, Target resolvables and commit
• Solver intransparent
  make existing information better visible
• Atoms
  to be replaced by conditional dependencies
• Library too big
  split into download, parse, consume, refresh

Requirements

- the order does not indicate importance - - the numbers are purely for reference -

1. Speed
2. Handle lots of repositories with lots of packages
3. Better user feedback
4. Support GUI/CLI/CIM
5. Tighten coupling of patches to Pkg/Msg/Script
6. Small memory footprint
7. Proper locks
8. Security (signed sources, packages, etc.)
9. Repository prioritization
10. Conditional dependencies / more expressive dependencies
11. Faster dependency solving
12. Unix philosophy (set of small tools)
13. Community involvement
14. Role based access
15. chroot environment / set up virtual images

Proposed Solutions

- numbers in parantheses reference requirements above -

• Factor out repository handling
  • Repository manager handles add/refresh/remove incl. downloading/parsing (1, 2, 12)
  • Repository and package management are separate (12)
  • Parse asynchronously to database, dependency solver operates on database (1, 2, 12)
  • Asynchronous refresh
• Transaction based
  • no more static ResStatus (1, 6)
  • no more all resolvables in memory (1, 6)
  • no more static pool (1, 6)
  • stateless operation, state is in application instead of library (1, 6)
• Dependency expressions (10)
  • no more freshens (5, 10)
  • no more atoms (5, 10)
  • support conditionals (if/then) (5, 10)
  • support and/or (5, 10)
• Query based API
  • Don't iterate over pool, but query for it (1, 4, 6)
  • Cache query results (optional) (1)
• Policies
  • Default policies -> sysconfig policies -> runtime policies (4)
  • for repo refresh (e.g. when to refresh, how often)
  • for solving (e.g. choosing the best package)
  • for commit (e.g. alternate download/install or download all/install all)
  • for caching (what to cache, how much to cache)
  • for repo priorities

Implementation

See here for details.

Further links

Abort repo download too slow/big Need source prio Strange (too hard?) deps Pattern/Detail UI confusing Repository types