[Rpm-metadata] metadata filenames and other issue for keying the data

[seth vidal]

> I've been looking at plugging apt into this new system.  Apt wants two
> files per repository (or, strictly speaking, distro-component pair),
> what I'll call the Packages and Release files.  Packages obviously
> corresponds to base.xml, but what about Release?
> 
> Release is optional, but a lot of apt's features hook in on that data. 
> Maybe the best way is to have a traditional non-XML apt Release file,
> and non-apt repositories can opt to provide a Release file if they feel
> a need to be apt-friendly.  OTOH, if we're talking about a general XML
> system, throwing in a little RFC822 data seems a little jarring.
> 

I think having a core file that tells you where the other data is,
provides an md5sum, and maybe a datestamp is incredibly handy. That's a
perfect way to have the base repository location easily collapsed into a
single url.


> There's also other.xml, but I don't want to download all the changelogs
> just to get to the tiny chunk of relevant data.

but there is nothing saying you have to download all the changelogs-  it
can be just a file apt knows how to find in case you want to get that 
information. That is how I plan on using it in yum, only get it if I
have to, otherwise it gets left alone.

> What if the package ID were something like a hyperlink to the package
> record in the file?  Dunno if XLink is up to the task, but it sounds
> interesting.  The base.xml entry could act as a the foundation, and
> other resources could link to the base.xml entry to add information like
> file lists, changelogs, etc.
> 
> <package type="rpm" xlink:label="apt">
>   <name>apt</name>
>   <stuff/>
> </package>
> 
> <package xlink:href="base.xml" xlink:label="apt">
>   <otherstuff/>
> </package>
> 
> While this seems to still have the problem with duplicates, your
> base.xml generator could put anything for the label, and could thus fix
> the problem by using NEVRA labels and tacking on extra identifiers.

It's not unreasonable at all - it wouldn't be hard to use the relative
path that the  base is derived from to track that part - b/c the
relative path to the files should stay the same but be unique for any
given file.

I think that the packageid looks cleaner - and I'm also considering that
someone might want a url schema that references a database, for example,
and then paths start looking a bit odder there. But a stored checksum of
the data will still work the same.

Does a checksum id cause problems on the debian end of things?

-sv