[Rpm-metadata] xml - first try

seth vidal skvidal at phy.duke.edu
Mon Sep 1 16:58:47 UTC 2003


>  At the URL given as an attrbute to the package tag.
> 
> > ie:
> > <rpm-location>http://www.mydomain.org/some/path/full.rpm</rpm-location>
> > 
> > let's say this is mirrored to some place - how do I know what relative
> > path from the metadata I should take to find that rpm?
> > 
> > Should I take: http://mymirror.org/some/path/full.rpm or just
> > http://mymirror.org/path/full.rpm?
> 
>    There is no way you can solve this problem at that level. 
> Suppose it's a redhat package. Where do you put the break between what's
> the local path from what is the expected mirror tree ? Any place you
> make that cut /pub, /pub/redhat, /pub/redhat/linux , you will find a mirror
> which just use a different one, heck I'm pretty sure I can find
> people who only mirror /pub/redhat/linux/current !

That's why you put it RELATIVE to the path where the metadata exists.

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.

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.

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

I'm not sure why a relative path is half-baked. It's just about the only
way to make mirroring work and if you can't find the file with regard to
the metadata then the metadata doesn't have much value in and of itself.

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 looked through the pkglist and PackageInfo files from apt and rc,
respectively, and they both make an allocation for a relative path.

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 -
specifically the bit about defining a base href and seeing all the links
as relative to the defined base href.

At least, that was how I read it.

ideas?
-sv







More information about the Rpm-metadata mailing list