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:
| ||
| 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 |
| ||
| 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)

