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

[Jeff Licquia]

On Mon, 2003-10-27 at 00:51, seth vidal wrote:
> 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.

That's a fair objection.

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.

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.

Maybe "releases.xml" is the best approach.

> Not sure, What does everyone else think?

Ditto.

> > 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 :)

Yes, definitely.  I wonder if the rpmfind/freshrpms/whoever people have
run into this with apt-rpm.  I vaguely remember some interesting juju
when feeding a repo to apt with two identical NEVRAs, but it was a long
time ago.

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

It's late, and I've been working hard, so I'll indulge myself in a
flight of fancy for your entertainment.

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.

<package type="rpm" xlink:label="apt_0:0.5.14-0_i386"/>
<package type="rpm" xlink:label="apt_0:0.5.14-0_i386_2"/>

Of course, one could also make the decision that stuff like the above is
always an error.  But it's not like the technology forces that decision
on you.

OK, you can cue the laugh track now.