[Rpm-metadata] A few questions about the format

seth vidal skvidal at phy.duke.edu
Sun Nov 9 19:53:43 EST 2003


> (1) The 'type' attribute in the package element. I can see the
> advantages of making this CDATA, so that we are not just restricted to
> RPM and Debian-based packages, but what are the suggested values? Should
> we say that this will be "rpm" for RPMs and "deb" (or what) for .debs?
> Are there other types we care about at the moment?

rpm for rpms
deb for debs
slack for slackware pkgs
sol for solaris pkgs
etc etc etc

> (2) What is the 'id' attribute on the checksum element for? It is always
> set to "YES" in the current version of rpm-md-dump.py, so it is not
> really like an XML ID value. If it has a real purpose, can we either
> make it have type ID (forcing it to be unique) or call it something
> other than "id"?

oh, no it's it not an XML ID value. I didn't realize the collision in
concepts there. id in the checksum tag means 'use it as the pkg id for
look ups in the filelists.xml and other.xml files'


> (3) Should the 'type' attribute on the checksum element be an
> enumeration, rather than CDATA? Should we list a set of recommended
> values that we support? Currently rpm-md-dump.py puts type='md5sum'.
> Multiple checksums are permitted by the DTD (which seems like a good
> idea). What values should we use for other common checksum types?

It will need to be updated whenever a new checksum type is used:
md5
sha
etc.


> (4) The 'epoch' attribute on the version element is required. Does this
> make sense for .debs? (I think we discussed this, but I cannot find the
> mail to back me up.)

I thought Jeff L. said that epoch is an existent identifier for debs,
too. Maybe required is incorrent, maybe it should be implied as null if
missing. I'm making epoch=0 if not exist in the rpm-md-dump.py code as
rpm, iirc treats an absent epoch as 0. Someone feel free to correct me
if I'm wrong about that.


> (5) In the rpm namespace, I suspect the 'flags' attribute on the entry
> element should be an enumeration of the possible flag types. There is no
> real case to be made that we will need to arbitrarily extend these (is
> there?), so lets just come up with the right set and enforce it.
> 
Well if we ever want to extend the flag data to include pre and post
info, etc, then it might be wise for it be more free form. Then again if
that time comes maybe it's time to do a revision of the metadata dtd.

Thanks for doing this Malcolm.

-sv




More information about the Rpm-metadata mailing list