[Rpm-metadata] metadata script and sample

[Jeff Licquia]

On Thu, 2003-10-02 at 23:42, seth vidal wrote:
> let me know what I screwed up.

You asked for it. :-)

I'm looking at this file from a Debian point of view.  It's a good
start, but there are a few things we'd need to be able to use this. 
There are also some technical suggestions I'd make.

Of course, I could be so off you will all laugh at me.  It's happened
before.

 - Miscellaneous RPMisms.

<vendor>, <group>, <BuildHost> (lowercase?), <header-range>, <color>. 
Also, <size rpm="foo"> should be <size package="foo">.  If these are
optional, cool.  It would be nice if they were in a namespaced <rpm>
area, like Debian-isms will have to be in a namespaced <deb> area, but
that's more a self-esteem thing than anything else.

 - Versioning and dependencies.

The versioning and dependency syntax is a little weird.  Its only real
deficiency is that it doesn't seem to handle or-relationships, but it
seems to me that it could be done better overall.

Allow me to pontificate on an idea I have.

Versions aren't three things; they're three parts of one thing.  So, it
seems to me that they should be expressed in a single entity, with the
components as entity attributes.  "epoch" and "release" should also be
optional.  So: 

<version epoch="1" main="4.2.1" release="3progeny1" />
<version main="0.5.14" />

Once you've done that, you can re-use the version entity in
relationships, with some kind of relationship quantifier.  Then, the
same code can parse package versions and dependency versions.

Also, since all relationship types have very similar handling, making
each relationship type its own entity seems inefficient and limiting. 
The type should probably be an entity attribute, not the entity itself. 
This also handles things like "proper" case, Depends vs. Requires,
Debian's lack of support for Obsoletes and its added relationship types
like Recommends, Suggests, and Enhances.

Finally, have each relationship scope (package, rpm capability, file,
etc.) have its own entity, and allow multiple relationships per entry. 
These would be interpreted as or-relationships; if any one is satisfied,
then the entry is satisfied.

Here's an example of what I'm thinking:

<dependency type="Requires">
  <entry>
    <packagedep name="foo">
      <comparison type="greater-than"/>
      <version main="4.2.1"/>
    </packagedep>
    <packagedep name="bar"/>
  </entry>
  <entry>
    <filedep path="/bin/sh">
  </entry>
  <entry>
    <rpmdep capability="CompressedFileNames">
  </entry>
</dependency>

That takes care of the aesthetic concern over uppercase dependency type
names, and also allows Debian to add things like Recommends, Suggests,
and Enhances without resorting to its own namespace.

 - <pkgid> should be <checksum type="md5">

This would allow us to add as many other checksum algorithms as we
wanted.

 - xml:base

This looks just unworkable, but maybe I'm assuming a purpose that isn't
correct.  Are we actually banning mirrors and CD repositories with this?

 - Does <location> take XPath references?

That's it for now.  Again, superb start, and I'm glad you're willing to
work with Debian on these things.