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

[Jeff Licquia]

On Tue, 2003-10-28 at 00:35, seth vidal wrote:
> > 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.

I don't see the two-file system as a serious problem; I'm just looking
at two types of data that I need to suck down somehow.

So you're proposing that package-manager-specific metadata could be
stored in separate files and indexed by the core file, a la
"release.xml"?

Maybe an example would help.  Forgive my denseness; maybe I should just
shut up until you've implemented this and object if I need to then.

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

Right.  But I was referring to a big catch-all miscellaneous metadata
file, namespaced out the wazoo.  I agree that separate files are better.

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

Well, take that fever dream of mine for what it's worth, or not.  It
just struck me as worthy of consideration.

In defense of XLink, while a URI like
"/metagen/packages.cgi?dist=woody&arch=i386#apt_0.5.14" might look a
little odd, it is still more descriptive as a standalone entity than
"11a59f54c0662fca097c29d1356b2f90".  And with path virtualization magic,
the former could be made even more readable.

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

Sorry for ignoring this discussion; I thought it was answered.  No, I
don't see any problem with full-package checksums as IDs for either .deb
or .dsc packages, especially the way you've constructed it.