Re: metadata filenames and other issue for keying the data

> Is there a reason why these files need to be in a subdirectory?  

no, not really.


> If the toplevel metadata file must contain timestamps and checksums,
> could it not also contain paths?  For an example, look at a Debian
> Release file:
> 
>   http://ftp.debian.org/debian/dists/woody/Release


To have the file locations listed elsewhere is fine by me.


> I'd also imagine metadata.xml would need namespacing.  It seems that it
> would stand in as a Release file for apt, and so might need to contain
> more than just file information.  Again, look at the above file for an
> example of what might be expected.

my only objection about this file being used as Release is that it seems
like it's overloading this file with other information unrelated to the
package metadata. I'm not opposed to it, per-se, I'm just trying to
figure out if the data it needs to store and the other data in the
Release flag are really correct to have together.

Not sure, What does everyone else think?

> It's possible.  For what it's worth, apt doesn't allow this condition -
> not in a single repository, anyway.

gotcha, yum does, and more importantly it seems like one of those things
that could definitely happen on a site like rpmfind for a given scale of
metadata generation. (in a sufficiently large enough set of rpms,
someone has generally done something stupid :)

what I did in the latest edition of things was to make 2 changes:
1. <checksum type='md5' id='YES'>md5stringhere</checksum> - this means -
use this checksum as an id for the package
2. in the filelists.xml file I have <package id="md5stringhere"> - so
you can correlate one with the other, does that make sense?

I'll post the above soon.
-sv