[Rpm-metadata] metadata script and sample

[Jeff Johnson]

Darrin Thompson wrote:

> seth vidal wrote:
>
>> In general this is just a 'proof of concept script' but the stuff is
>> clearly the basis for what the metadata would look like.
>>
>
> I'm comparing the metadata file against the Debian way as I understand 
> it. Real Debian developers should feel free to correct me.


I'm glad to see someone from Debina, dpkg/apt and 
rpm/{yum,up2date,redcarpet} are more similar than not.

>
> Could the following fields be punted into an RPM specific namespace?
>
> pkgid
> license
> vendor
> group
> BuildHost (presumably you meant build-host?)
> header-range
> color
> url
>
> Also, the following fields could possibly be mapped to deb fields:
>
> packager - Maintainer
> requires - Depends
> provides - Provides
> conflicts - Conflicts
> obsoletes - Replaces


Instead of agreeing to disagree and hiding constructs in private name 
spaces, is there a chance
that common representattion and semantics can be mapped out?

I don't know of any overwhelming hurdles in unifying the representation 
of dependencies between dpkg/apt and rpm/{yum,up2date,redcarpet}.

If we can't unify, private name spaces are always doable, but it seems 
to be a shame not
to try to work through a better, unified, representation.

>
> However, do the semantics of the fields really match from the 
> perspective of apt/yum/etc.?


The thornier issues are in the semantic interpretation, not in the 
representation, of dependencies.
A common representation of package metadata can only help deal with the 
thorns.

>
> I like the idea of applying XML Base to the location field. If I were 
> to a Debian repository converter, I would probably do this:
>
> <metadata xml:base="../../..">
>     <whatever href="pool/main/looks-just-like-Filename-field"/>
> </metadata>
>
> That would retain mirror friendliness and not hose anybodys current 
> flexibility, no?
>

73 de Jeff