[Rpm-metadata] xml - first try
Daniel Veillard
veillard at redhat.com
Mon Sep 1 17:49:22 UTC 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
--
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