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