[Rpm-metadata] Be careful with the format tag

[Darrin Thompson]

I believe that one of the purposes of these file formats is to be as 
extensible as possible. I'm a little worried about the format tag. The 
assumption that all differences between Debian and RPM based distros are 
due to the package format is limiting. Of course no one has said that 
outright but I think that's where we are headed.

The difference between RPM and .deb goes beyond file formats and into a 
mode of thinking about how to maintain an installed distribution. Debian 
is different. It's not because of .deb.

Both RPM and .deb are extensible. If you really wanted to you might even 
be able to shoehorn the semantics of .deb into the RPM file format and 
vice versa. That would have the added benefit of making some people 
really mad.

Also, in a Debian Packages file, each package entry contains three 
fields not present in the .deb: Size, MD5sum, and Filename.

Those fields have less to do with the .deb file format and more to do 
with _apt_.

The point is that we should be careful about making assertions about why 
fields are different between Debian and RPM based distros.

If yum and red-carpet decide that including extra metadata in a file is 
beneficial, that should be fine, as long as:

* They can do without it when it isn't present.
* apt and up2date can still work with their new repository format by 
ignoring the elements they don't understand.

Just using a raw namespace seems the most flexible.

<metadata xmlns... debian:license-section="contrib" >
   <package>
     <name />
     <rpm:BuildHost />
     <depends />
     <deb:suggests />
     <deb:enhances />
     <red-carpet:magic-arbitrary-metadata />
   </package>
</metadata>

By just using raw namespaces I've been able to specify the license of 
the packages in this file The Debian Way. (Ok not exactly but hopefully 
this illustrates the point.) An RPM repository would not need to include 
that field.

This seems to have the benefit of giving two groups exactly what they 
need. Apt/Yum/RC/u2d are guaranteed to find a minimum amount of data and 
can look for extra data if desired. Repository maintainers can support 
the additional features of the package tools with minimal impact.

-- 
Darrin Thompson
Progeny