[softwaremgmt] YUM metadata design problems and missing info
(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@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
On Tuesday 22 May 2007 14:06:38 Jan Kupec wrote:
(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.
That documentation does not exist. The documentation of the format exists in: *DTDs with improvements that are not yet implemented in the yum programs. see: https://lists.dulug.duke.edu/pipermail/rpm-metadata/2006-November/000734.htm... * Our rng schemas, outdated.
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.
I agree with the same, now that zypp svn is public, we can link the files from the wiki, the right place is: http://en.opensuse.org/Standards/Rpm_Metadata
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.
I have no clue how xml:base semantics are, I remember that Michael Schröder asked me once about it.
- updatescript - what is it? is it a redundancy in addition to script atom?
Can be removed I guess.
- license-to-confirm (see bellow)
The name is stupid. As we use it to confirm anything, the name should be more general. "message-to-confirm" or something.
- filename can be found in patchrpm/location[@href]? - downloadsize == patchrpm/size[@package]? - m5sum - isn't patchrpm/checksum enough? - buildtime == patchrpm/time[@build]?
md5sum should not be an atrribute. That is inconsistant, other parts of YUM already use <checksum type="xxx">yyyyy</checksum> Of course that element is also broken, because they use "sha" instead of "sha1".
- size attributes - we use them as follows: - package - rpm file size - installed - installed size - sum of unpackged contents - archive - ?
Perhaps cthiel can help here.
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).
Isn't the language in a lang= attribute here? Duncan -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
On Tuesday 22 May 2007 14:06:38 Jan Kupec wrote:
(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.
That documentation does not exist. The documentation of the format exists in:
*DTDs with improvements that are not yet implemented in the yum programs. see: https://lists.dulug.duke.edu/pipermail/rpm-metadata/2006-November/000734.htm... * Our rng schemas, outdated.
I will update them one by one, but need info.
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.
I agree with the same, now that zypp svn is public, we can link the files from the wiki, the right place is:
Great. Yes, this is the link [1] :O) I will take care of it.
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.
I have no clue how xml:base semantics are, I remember that Michael Schröder asked me once about it.
- updatescript - what is it? is it a redundancy in addition to script atom?
Can be removed I guess.
I like removing stuff :O)) does anyone object?
- license-to-confirm (see bellow)
The name is stupid. As we use it to confirm anything, the name should be more general. "message-to-confirm" or something.
Or we should not use it for things other than confirming agreement with license and use other tags for other things if we need them.
- filename can be found in patchrpm/location[@href]? - downloadsize == patchrpm/size[@package]? - m5sum - isn't patchrpm/checksum enough? - buildtime == patchrpm/time[@build]?
md5sum should not be an atrribute. That is inconsistant, other parts of YUM already use <checksum type="xxx">yyyyy</checksum>
I agree, if no one objects, i'll drop it :O)
Of course that element is also broken, because they use "sha" instead of "sha1".
So i just replace the "sha" with "sha1"...
- size attributes - we use them as follows: - package - rpm file size - installed - installed size - sum of unpackged contents - archive - ?
Perhaps cthiel can help here.
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).
Isn't the language in a lang= attribute here?
Nah! A wrote it incorrectly. The { localized-string }* is OK. But in patch.rnc the patch element is allowed to contain *muliple* license-to-confirm*. Thus the ambiguity. Several different licenses with translations is the problem. Jano -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
* Jan Kupec
(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.
The official place for documentation should(!) be http://linux.duke.edu/projects/metadata/ but it isn't :-(
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.
I support this vote. Now that libzypp svn is publically available, opensuse.org should contain links to the relevant svn files and probably add some 'newbie' information.
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.
IMHO supporting xml:base would be the right step.
- update-script - what is it? is it a redundancy in addition to script atom?
A script to be run when the patch gets updated (as opposed to being installed first-time)
- license-to-confirm (see bellow)
A patch might be bound to a license. But I don't think this is the right semantics, a message should be used here. The intention for messages is that not all problems might be fixable automatically (by package updates or scripts) but some might need user interaction (resp. user acknowledge). A license is not different from a message the user has to acknowledge.
- 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]?
Michael Andres should be able to answer this.
- size attributes - we use them as follows: - package - rpm file size - installed - installed size - sum of unpackged contents - archive - ?
iirc, 'archive' is synonymous with 'package'. This topic was discussed last year and should be in the wiki somewhere ...
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).
The license translations should be handled like translations of package summary and description. Looking at the sizes for all translations, it might be better to move them to per-locale files long-term. Klaus -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (3)
-
Duncan Mac-Vicar Prett -
Jan Kupec -
Klaus Kaempf