[Rpm-metadata] xml - first try

Daniel Veillard veillard at redhat.com
Mon Sep 1 14:49:22 EDT 2003

On Mon, Sep 01, 2003 at 12:58:57PM -0400, seth vidal wrote:
> We talked about this over dinner a while back. You have to have some way
> of mapping the metadata to a path to an rpm.
> If all of the metadata points to:
> ftp://ftp.redhat.com/pub/redhat/linux/9/en/os/i386/ Then how do we get
> the rpm out that the metadata represents. If you're on
> mirror.dulug.duke.edu you can't b/c our paths are not always the same.

  Either you use an URL for your copy, more precisely an URI-Reference
which can be relative, or you use other metadata to associate the 
canonical URL to the local one.
  I think the metadata must point clearly to the package it reference
and that URI must be a normal URI reference (absolute or relative it
doesn't matter, you can even use xml:base if you want).

> but if you generate the metadata into the
> /pub/redhat/linux/9/en/os/i386/ dir - then put relative paths to the
> files then you can mirror and still provide useful metadata.

  We should not build the spec with any expectation of support from the
source distro, I think the default mode is that at least some mirror will
rebuild them.

> >   That metadata is a package metadata, let's not mix everything, I agree
> > there is also a need to set up a mirroring metadata infrastructure, but 
> > a half baked solution duplicated in all the package metadata is really
> > not an answer IMHO :-) [*]
> And LOCATION is CRITICAL to the metadata. Not original location,
> location right now.

   Then point at it, I didn't say a relative URI wasn't okay, but a split
path is confusing and the location must be complete (and clearly associated
at the package tag IMHO)

> I'm not sure why a relative path is half-baked. It's just about the only

  Half backed was the 3 paths, left to the user the way to assemble them
to try to decypher what this metadata is talking about.

> That's why I split up the url like I did - to make it so an application
> reading that could re-assemble the url to the original location where
> the metadata file was generated or just use the relative path +
> filename.

  I found that too complex. put an <original>URL</original> absolute
URL too if you want but the 3 paths IMHO mixes mirroring metadata within
the package metadata, this does not sound clean to me.

> I thought this was what we had talked about before. I had suggested a
> relative path, pzb had said - no make it a complete uri, I raised the
> issue of mirroring and you suggest a rfc2396 compliant uri -

  yep and still do.

> specifically the bit about defining a base href and seeing all the links
> as relative to the defined base href.

   the problem is that that base is dependant on your infrastructure.
not a base related to the way to interpret URI-References per the RFC
that would be xml:base on some element.


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

More information about the Rpm-metadata mailing list