[Rpm-metadata] A few questions about the format

[Jeff Licquia]

seth vidal wrote:
>>(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

If you'd like examples of non-RPM data in this format, check out my 
site: http://hackers.progeny.com/~licquia/rpm-metadata/

I'm currently working on updating my tools to reflect the recent work, 
but the above should give you some idea of what could be done.

>>(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.

Debian versioning uses the same system as RPM, with epoch, upstream 
version, and package version (or release).  The main differences are 
that epoch and release are optional in Debian, and that there aren't 
separate fields for each piece of the version.

So:

Package: apt
Version: 0.5.14
(no epoch or release, version 0.5.14)

Package: libc6
Version: 2.3.2-6
(no epoch, version 2.3.2, release 6)

Package: mozilla
Version: 2:1.5-2
(epoch 2, version 1.5, release 2)

For the purposes of the metadata format, one could assume 0 for missing 
version information.  Epoch 0 is not used in Debian, and release 0 is 
always used with some kind of qualifier for certain types of updates 
(for example, "0woody1") as dictated by Debian policy.