May 2007 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] missing docs
by Jan Kupec 11 Jun '07

11 Jun '07

Following is a list of docs i had been missing when starting to work on zypper and later on libzypp: - 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. [1] and [2] is not enough when it comes to development of client soft and using libzypp and development of libzypp itself. - Vocabulary - Resolvables - what are these and what kinds of them are there? FIXED[1]. - (Installation) Source vs. Catalog vs. Repository terminology explanation. - code organization - what is what in the source dir tree (purpose of the code) FIXED[1] - Class design - info on the design patterns used (Bridge/Impl and others). If the newcomer is not familiar with these, he/she's just lost :O) - compiled zypp devel guide such as: - 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... - Class diagram Martin Vidner and I already started to create one while working on zypper, using ArgoUML tool. See doc/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! - 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). - there are probably more, but i can't recall or go through them all now, we should send a notice about missing docs as we come across some. The links: [1] http://en.opensuse.org/Libzypp/Design [2] http://en.opensuse.org/Libzypp/Package_Management Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] patches, atoms, and the delta and patch RPMs in metadata (YUM)
by Jan Kupec 11 Jun '07

11 Jun '07

Hi hackers, while redesigning various parts of libzypp a question has been raised about incosistencies/misdesign we currently have in our YUM metadata extensions and ZYpp regarding patches. INTRO: In metadata, a patch includes atoms: element atoms { (element-package | element-script | element-message)+ }+ and the package element is an extension of a normal yum:package: element-package = element yum:package { package & element-pkgfiles & (element license-to-confirm { localized-string }?) } where pkgfiles are the delta, patch or plain rpm file data. In libzypp, delta and patch rpms are appended to Package which, basically represents a plain rpm package resolvable. The rest of the /patch/atoms/package data is an Atom resolvable (with its own dependencies), a helper resolvable used to resolve patch dependencies. PROBLEMS: Well, for me as writer of the new YUMParser it is just a question of mapping the data to classes in libzypp (ResolvableData). Experienced zypp hackers can add more... SUGGESTIONS: ? Attaching current version of patch.rnc and patch.rng for convenience. See also: http://en.opensuse.org/Libzypp/Patches/Rationale http://en.opensuse.org/Libzypp/Metadata/repomd/patches (not very informative today, but will be expanded) Cheers, Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 3

[zypp-devel] Status and tasks.
by Duncan Mac-Vicar Prett 30 May '07

30 May '07

Added more diagrams: http://en.opensuse.org/Libzypp/Refactoring#Repository_Handling - The annoying bug with zypp not rebuilding when headers touched is fixed. Thanks to the cmake developers for the help. Misc tasks: - Go trough Resolvable public attributes, and save them in the CacheStore, see consumePackage (the only implemented, and probably attributes missing). - Complete CachedResolvable different implementations. - Figure out a nice way to probe sources. Nice from the architecture, so it is not if else code. The repomanager needs that. Jano posted more status from his side. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] status
by Jan Kupec 29 May '07

29 May '07

YUMParser is ready. Last week i completed the patterns.xml and products.xml parsers and cleaned-up the code a bit (comments, separated implementation from public API). I have to add support for AbortRequestException and ParserException yet (few hours). groups.xml will be supported and implemented later (we will try to interpret it as patterns instead of selections). Soon, i'll add some missing attributes to CacheStore consume*() methods (1 day?). After that i'm free to do whatever what gets high priority. jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Things TODO in CacheStore
by Jan Kupec 25 May '07

25 May '07

Duncan, what i was talking about is storing all the rest of the data other than NVRAD and kind in these methods: consumePatch() consumePackageAtom() consumeMessage() consumeScript() consumePattern() consumeProduct() Do you want to code it, or shell i? There is some work on the YUMParser stuff yet, but after polishing the code i'm free to do other things. FILELISTS AND CHANGELOGS of YUM Also, what has to be solved (with low priority, though) whether we can support interface like: void CacheStore::consumeFilelist( const data::RecordId &catalog_id, const data::Resolvable_Ptr & resolvable, const data::Filenames & filenames ) This would mean querying the DB for the resolvable of given kind and NVRA in given catalog and appending the changelog/filelist to it. You said that it is not possible since the kind and NVRA are not unique within one catalog? If this would be possible, the YUM parser will have very low need for memory (suse tags will probably not benefit from it(?)). If we don't agree on this way (or if it turns out to be slow), then i would like to have API like: void CacheStore::consumeFilelist( data::RecordId &resolvable_id, const data::Filenames & filenames ) With such API i will be remembering a map of yum package IDs to resolvable record IDs and use it to insert the filelist and changelog or whatever with still low memory foot-print. Otherwise i will need to read all the package/filelist/changelog data of all packages into memory. What do you think? Jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 5

[zypp-devel] Writing tests guide...
by Duncan Mac-Vicar Prett 24 May '07

24 May '07

Basic concepts and test template. http://en.opensuse.org/Libzypp/WritingTests It explains how to create unit tests. The solver test cases part is minimal for now (as my knowledge there is also basic). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] Libzypp version now in logfile
by Michael Andres 24 May '07

24 May '07

YFYI: [zypp] ZYppImpl.cc(ZYppImpl):137 libzypp: 3.2.2 built May 23 2007 19:32:40 [zypp] ZYppImpl.cc(ZYppImpl):138 defaultTextLocale: 'en_US' [zypp] ZYppImpl.cc(ZYppImpl):139 System architecture is 'i686' Upon construction ZYppImpl now logs it's version and buildtime. Provided we'd properly maintain the version info, it's easy to tell whether a certain feature/fix/bug should be visible in a log. Exp. if we release more than two zypp versions a day. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 4

[zypp-devel] Cache Schema
by Duncan Mac-Vicar Prett 23 May '07

23 May '07

- SInce revision 5613 the cache sql schema is not longer read from an installed file in /usr/share, but converted to C code during build. That means you don't need to have the schema installed, useful for testcases for example, and easier to manage in general. Also, the schema is still maintained in its own, non-C++ file, which is easier to edit than a super long C++ string. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] YUM metadata design problems and missing info
by Jan Kupec 22 May '07

22 May '07

(posting also to zypp-devel, but pls. discuss it on opensuse-softwaremgmt) First of all, if anyone can point me to an existing documentation of YUM xml schemas WITH comments on semantics, please do so. What we have on opensuse.org [1] and libzypp svn [2] is not enough (i will extend the info with what i've learned so far ATP) and digging the code that actually uses the data doesn't allways help. Also, we should agree what should be an authoritative place for specifications. The bare schema (rnc|rng|dtd) files are good for validation, but not for exact specification and semantic docs. But if commented, it would make a difference. Or should [1] be used? I'd vote for comments inside RNCs with a link to them on wiki. Some unclear things: patch.rnc - xml:base + href (anyURI) seems like we ignore xml:base attribute of all location data (not only in patch.xmls) and use just href as a relative path to a file on source URL. What about stating it somewhere in docs explicitly and dropping xml:base from suse extensions completely. Or start to support xml:base. - update-script - what is it? is it a redundancy in addition to script atom? - license-to-confirm (see bellow) - rpm base attributes redundant? patchrpm and deltarpm elements both have attributes that seem not be used and redundant: - filename can be found in patchrpm/location[@href]? - downloadsize == patchrpm/size[@package]? - m5sum - isn't patchrpm/checksum enough? - buildtime == patchrpm/time[@build]? - size attributes - we use them as follows: - package - rpm file size - installed - installed size - sum of unpackged contents - archive - ? suse-primary.rnc - license-to-confirm { localized-string }* this has multiplicity zero-or-more, but there is no way to tell particular translations apart except to rely on tag order, which is (by definition) undefined. Either we add an identifier to the tag or we add <licenses> tag to encapsulate them (or we remove the multiplicity). Cheers, Jano [1] http://en.opensuse.org/Standards/Rpm_Metadata [2] http://svn.opensuse.org/svn/zypp/trunk/libzypp/zypp/parser/yum/schema -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] YUM patterns metadata
by Jan Kupec 22 May '07

22 May '07

Hi! (posting also to zypp-devel, but pls. discuss it on opensuse-softwaremgmt) At http://svn.opensuse.org/svn/zypp/trunk/libzypp/zypp/parser/yum/schema you can find the current state of patterns metadata schema (patterns.rnc and rng). We never used patterns in YUM sources so far, so there is some space to make changes to it as we need. So please post comments, suggestions. Multiple pattern*.xml files or a single one? I have one suggestion to start with: let's keep patterns in one file by adding <patterns (maybe some attributes e.g. count)> element to encapsulate the <pattern> elements: .... start = element-patterns .... element-patterns = element patterns { pattern+ } .... Currently, there would be zero or multiple <data type="patter"> entries in repomd.xml. BTW: the same question applies to products as well Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1