May 2007 - openSUSE Software Management

[softwaremgmt] .repo files
by Duncan Mac-Vicar Prett 14 Jun '07

14 Jun '07

We are designing the new repo handling model of the SUSE package manager stack to be more compatible with YUM, smart and the build service .repo files. When I looked at the .repo files at the first time, I thought the baseurl= was a unique url, which was the url of the origin of the metadata (used to identify), and the actual urls were pulled from a mirror list. I was confused for a bit when I discovered a .repo can have more than one baseurl. Even more when saw the strange way to do multi-line in the ini file. That means basically, there is no url you can use to, in the case you add a .repo file which has a list of urls, but the same base url as an already existing .repo, just append the urls to the mirrorlist. Ok, that sucks (as much as the documentation). But now comes another problem. Our (broken) model, requires a pair (url, path). If we support more than one baseurl in the .repo file, you can't have path as a separate unique attribute. .repo files doesn't specifiy path. I think the best solution is to get rid of path completely. Do we need it? no. It is needed in CD, NFS only (probably ISO too?) because we are using it in a wrong way. Can aynone give examples? why is needed? I am sure we can destroy those examples using the standard Url structure (and abusing options) Duncan -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

5 6

[softwaremgmt] YUM metadata design problems and missing info
by Jan Kupec 12 Jun '07

12 Jun '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: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 3

Re: [softwaremgmt] YUM patterns metadata
by Michael Matz 22 May '07

22 May '07

Hi, On Tue, 22 May 2007, Duncan Mac-Vicar Prett wrote: > > mental model of patches is a blob of dependencies and some file deltas, > > where the file deltas is the more important part. But I guess it's not > > important how my mental model is. It doesn't help nor hinder their > > implementation as actual rpms. > > Actually they are just metadata that depends on newer rpms. The fact > that some of these rpms can be installed downloading delta/patch rpms is > something evaluated at commit time and not at solving time, thus the > patch does not need to know about rpms at all, it only need to express > which version of a group of packages fixes the problem. The commit logic > should grab and rpm and install it, or download a script and run it to > patch a binary, or get a delta rpm, or untar something in /. > > So the file delta is just an implementation detail, but it is not in the > patch itself. Right. That's why I said my mental model of patches includes the delta. If it really is inside the patch or not (or for that matter if a patch consists of one file, or a set of files) wasn't that interesting for me in that discussion. It's obvious that the file delta part of patches is better implemented as dependencies on versioned rpms, instead of duplicating them directly into the physical patch. But conceptually (to me!) a patch includes that delta. But that's all not very important. What's much more important IMHO is to try to implement patterns as rpms. > Note: in our current metadata it is, but just because the patch format > is missdesigned. They not need to be there (therefore all packages are > duplicated inside the patch and the primary file!!) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] 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: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

4 7

[softwaremgmt] Welcome to opensuse-softwaremgmt !
by Duncan Mac-Vicar Prett 21 May '07

21 May '07

Hi! Welcome to opensuse-softwaremgmt! This mailing list has one mission: bring the people involved in different projects having to do with package management, together. Like: - ZYpp developers - Autobuild & build service - Updater applets and YaST modules. - Community in order to: - define metadata formats, standarize, push upstream, create specifications and centralize the knowledge. - coordinate features in one componet to be used by other components. - discuss ideas to make the user experience better (how to make downloading metadata faster?) - coordinate community projects in order to integrate them with other components. - Discuss having common codebase for tools like metadata generators, validators, packaging tools, etc. -- 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: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0