Libzypp/Refactoring/Timeline

From openSUSE

Contents

Introduction

This is a timeline for ZYpp development. Please use this [1] syntax to link references

Events

Date Event Description References
01.05.2007 Profiling data RPM backend profiling data added Libzypp/Profiling
03.05.2007 ProgressData Improve progress reporting for long running tasks Libzypp/Implementation/Progress
07.05.2007 Repo Handling New IniParser, IniDict, section and entry iteration, tests
13.05.2007 Cache store improvements All attributes can be saved. Refactoring/CacheSchema
11.05.2007 Repository handling use cases Tasks and components involved. Refactoring#Repository_Handling
21.05.2007 Checksum and GPG handling Fetcher supports file checking Libzypp/Metadata_Signature
06.06.2007 YUM parser is ready Libzypp/API/YUM/RepoParser
19.06.2007 ZYpper can handle repos and install packages Libzypp/Zypper

Issues / TODOs

Date Prio Task Description References
25.04.2007 M source list, passwords in urls? Right now, source list is only root readable, because url passwords. <none>
26.04.2007 M better parsers susetags and repomd parsers should be faster and only read/store whats actually needed <none>
26.04.2007 M parsers fill cache have new parsers be able to write to database <none>
26.04.2007 M handling of translations translation data is huge and often duplicated, how to handle this ? proposal
26.04.2007 D cache needs disk usage 'susetags' also provides detailed disk usage information, how to handle it ? packages.DU file
26.04.2007 M cache refresh how and when to refresh the cache proposal
26.04.2007 M documentation we need a description of directory layout, namespaces, and filenames in libzypp source code <none>
26.04.2007 M RepoManager The old 'inst source' code should be redesigned (and renamed to Repo...) <none>
26.04.2007 D compressed metadata Any metadata file might be compressed, parser should handle this transparently proposal
26.04.2007 M parser validation mode In order to check metadata immediately after generation, all parsers must provide a verification mode and a command line frontend <none>
26.04.2007 M adapt yast pkg-bindings pkg-bindings are broken and must be adapted <none>
26.04.2007 D make rpm reading faster reading the rpm database is slow in zypp compared to other solutions, why ? <none>
26.04.2007 D repository attributes InstSource has lots of attributes, which of them are actually used/useful ? <none>
26.04.2007 D smart channel concept Smart knows about channels (repositories) and their mirrors <none>
26.04.2007 D zsync Can we use zsync for metadata refresh ? here
26.04.2007 M repo handling Implement Duncans repo handling proposal <none>
26.04.2007 F package search integrate package search for YaST and buildservice. Wait and see what comes out of the portal work. [2]
30.04.2007 M separate package download and installation download RPMs to local cache, install from local cache <none>
30.04.2007 M transaction/commit handling make commit flexible here
30.04.2007 M metapackages combine repo subscription and package install [3]
10.05.2007 M options and policies concept for handling and distribution of options and policies here
23.05.2007 D progress reports Improve progress reports to supply more detailed information. Support multiple tasks and a common way to handle abort requests. here
14.06.2007 M repo file/media layout Storing the repository url (and no longer media/path on media) breaks current media change and media verification for reositories not located at /. [4]
14.06.2007 M repo file/passwords Make /etc/zypp/repos.d world-readable and store passwrods in a separate file accessible by root only. [5]
19.06.2007 M Url variables .repo files can contain variables in urls [6]
19.06.2007 M Cache schema versioning workflow to rebuild cache?

Documentation TODOs

Date Prio Task Description References
D library overview library overview - it's purpose and abilities, what it can offer to the clients (particular functionalities e.g. it can open a repository and load all the resolvables it contains into some structure) and how (intro on using pieces of it in the client code). This should be in one place. Libzypp/Design and Libzypp/Package_Management is not enough when it comes to development of client soft using libzypp and development of libzypp itself. Libzypp/Design, Libzypp/Package_Management
M terminology (Installation) Source vs. Catalog vs. Repository terminology explanation.
D design patterns info on the design patterns used (Bridge/Impl and others). If the newcomer is not familiar with these, he/she's just lost :O)
D compiled zypp devel guide

something like:

  • use logger (MIL << ...) look HERE for docs
  • use exceptions like this (ZYPP_THROW ...) look HERE for docs
  • use smart pointers, look HERE for docs
  • use THESE patterns, look HERE for docs
  • define callback base structs in ZYppCallbacks.h if you need to communicate or request info from client soft. again, see HERE for docs.
  • etc...
D class diagram

Martin Vidner and Jano Kupec already started to create one while working on zypper, using ArgoUML tool. See libzypp.zargo. You can open the file using ArgoUML, or uznip it and see what's inside. Problem is, the tool still does not support C++, it's not packaged for SUSE, and, well, creating a proper class diagram for libzypp is a huge task.

But a printable class diagram with all classes, with at least inheritance, aggregation and composition relations drawn-in would be more than useful. We should agree on one tool (maybe the ArgoUML at last, it is usable) and be responsible for updating it as we modify the API. NOTE: this should document implementation as well as public API!

libzypp.zargo
M code documentation
  • documentation of Exceptions - when a particular exception is or should be thrown
  • Resolvables - what does particular resolvable kind represent, what is the corresponding piece of data in metadata (susetags/yum impl. separately).
  • (add more here if you find something missing)
D glossary List of concepts with explanation and corresponding classes/methods/workflows which implement them. Preferably in doxygen with links to the respective classes/methods.

(Prios are Mandatory, Desirable, Nice to have, Future)