Re: Exposing split media
seth vidal <[email protected]>
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <1131610302.9209.77.camel@cutter> |
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