Re: Exposing split media

Paul Nasrat <[email protected]>
Newsgroups gmane.linux.rpm.metadata
Organization Red Hat, Inc.
Message-ID <[email protected]>
On Thu, 2005-11-10 at 03:11 -0500, seth vidal wrote:
> 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.

Yes, or a splitrepo command to add that information in.

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

I was assuming it would only be on disc1, - I don't want to parse each
disc in the set for the data, if you if you specify base in the location
for the included xml to point at disc one then you could have just the
repomd.xml on each disc should you want.

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

Sure, for the first stab, this is going to be used in anaconda, and we
can extract the more general mechanism for generating/mapping as we go
along.

Let me get something specific for test1 knocked up today and we can
reiview/work on it post 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

This is what I was going to look at today, plus the reassembly side in
anaconda.  I'd hope eventually we have generic reposplit tool as part of
yum-utils, but for the moment time is the critical factor so that may be
post test1.  

>   or
>  - create a new metadata file named location.xml containing the
> package->media map

That's fairly straight forward too, if I have time I'll generate this
too.

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

Also it's not another file to parse, and we already had the info in our
package objects.

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

To be honest we're not really abusing base here, just defining another
uri type that has more complex behaviour and allowing multiple bases per
repo.  

The more I look at it basepath seems like the correct place, 

Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.