[Rpm-metadata] metadata script and sample

Jeff Johnson n3npq at nc.rr.com
Fri Oct 3 22:00:31 UTC 2003


Jeff Licquia wrote:

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

Again I'd like to see a unified representation, as agreeing to disagree 
and hiding
essential data in private name spaces will only delay the harder 
semantic interpretation
issues of package metadata.

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

Yes, rpm packages lack a way to specify a logical or for dependency 
relations,
perhaps always will.

That does not prevent designing a metadata representation that can 
express a logical
or-relation. A sensible heuristic like
    Most likely (i.e. "important") relation first, please.
would probably permit a common interoperable representation of dependencies.

>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: 
>  
>

There's a rul that missing epoch == epoch: 0 going to be needed, and the 
extension missing
release == release 0 that would be needed.

Actually, I'd claim that dependencies are a 4-tuple, not a 3-tuple. The 
3-tuple identifies
a point on a single dimension, while the logical comparison specifies an 
inequality.

One might want to include the name as well, making a dependency a 5-tuple of
{Name,Epoch,Version,Release,Flags} where Flags determines the inequality.

Otherewise, yes.

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

If a 5-tuple, the above could be expressed more compactly.

>    <packagedep name="bar"/>
>  </entry>
>  <entry>
>    <filedep path="/bin/sh">
>  </entry>
>  <entry>
>    <rpmdep capability="CompressedFileNames">
>  </entry>
></dependency>
>  
>

Is there really a need for differentiating file/package/other 
dependencies like this?
file dependencies are easy, they always start with '/' anyways. I can 
possibly see
a need to mark a package dependency differently so that it was easier 
for dpkg to
distinguish during xml parse; otherwise dependencies are pretty much 
strings.

Well there are foo.so soname dependencies, and perl(yadda) dependencies, 
but all
are just strings from a rpm POV.

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

What is missing here is the semantic interpretation for "pkgid", i.e. 
what blob
is the digest calculated from. That can be dealt with outside of XML.

In fact, I would claim that the pkgid should not have any qualifiers 
whatsoever other
than bit/byte lengt and a promise of sufficiently unique.

Building in a checksum type prevents other identifiers that are 
sufficiently unique.
Perhaps a single type identifier might be needed for extensibility, but 
it should not
directly refernce the type of digest, but rather the type of the identifier.

OTOH, renaming to filechecksum rather than pkgid is perfectly adequate for
what Seth has proposed, and then a type might be perfectly reasonable.

I cannot disambiguate the two interpretations without a hint of what is 
intended,
am groping blindly with my interpretation of "pkgid".

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

HTH

73 de Jeff





More information about the Rpm-metadata mailing list