[Rpm-metadata] Exposing split media

seth vidal skvidal at phy.duke.edu
Thu Nov 10 08:11:42 UTC 2005


On Wed, 2005-11-09 at 10:50 -0800, David Lutterkort wrote:
> On Wed, 2005-11-09 at 13:00 -0500, Paul Nasrat wrote:
> > Currently createrepo with -u creates a base attribute, I wonder if it's
> > too much abuse to do:
> > 
> > <location xml:base="media:/rawhideYYMMDD/#1"
> > href="Fedora/RPMS/perl-Inline-0.44-15.noarch.rpm"/>
> 
> I never figured out what that attribute is supposed to represent (I
> think being in the xml namespace kinda throws me off), but IMHO that
> would be the most elegant solution.
> 

We're going to need to modify createrepo so it builds the fragment out
based on _something_ in the path.

I'm assuming that the goal of the metadata is to be on every disk in a
media set and be able to tell you where to find any package in the media
set. So we'll need some way of telling createrepo "these packages are
disc1, these are disc2, etc etc etc" when we're making the metadata,
right?

It could be done with a simple input file or just subdirectory
separations but I'd like some way of specifying that.

That also ties into David's idea of being able to make virtual
repositories of arbitrary packages w/o having to have the packages
themself. So we could possibly:
 - generate the metadata w/o the media/base path on the actual packages
or 
   download existing metadata from a previously created repository.

  Then:
 - generate a file mapping package->media/basepath
 - combine media/basepath + previously created package metadata into new
set of metadata, rewriting primary.xml and repomd.xml for new content
  or
 - create a new metadata file named location.xml containing the
package->media map


The reason I like the idea of having a package->basepath map that
createrepo could take for input to generate the new primary.xml is to
avoid arbitrary 'subdir mapping' code happening in createrepo.

However, having a separate packages->location xml file that is included
in the metadata in the same way that the groups files are currently adds
some flexibility and doesn't disrupt anyone using the location base
attribute currently.


-sv





More information about the Rpm-metadata mailing list