Re: Exposing split media

On Tue, 2005-11-08 at 21:29 -0800, David Lutterkort wrote:
> On Tue, 2005-11-08 at 19:10 -0500, Paul Nasrat wrote:
> > I'd like to propose a standard, optional extension to the rpm metadata
> > for handling split media, it serves as a hint to the metadata parser in
> > order to determine location:
> 
> Why not make it a little more general purpose: 

Sure, hence me asking for discussion :)

> what your example is
> saying is that the packages aren't to be found relative to the baseurl
> of the repo, but relative to another location (which in your example is
> the number of the CD), so that your example would look like

Yes - or that some action needs to take place - in our case eject and
insert, the packages will be at the repodata uri file:///mnt/source at
the location as described in packages Fedora/RPMS, once that action is
taken.

>   <packageset name="fedora-cds">
>     <part base="media:/cdrom1">
>        <package pkgid="..">
>          <version ../>
>        </package>
>        .. more packages ..
>     </part>
>     <part base="media:/cdrom2">
>       .. packages ..
>     </part>
>     ..
>   </packageset>
> 
> The media scheme in the 'base' URL is something I made up for the
> purposes of anaconda (which I assume this is coming from).

I like this format, I was struggling to come up with a uri syntax for
spanned media, I looked around, but nothing really seemed to have
standardised on a way to do this.

> Since this is essentially attaching additional metadata to each package
> (the name of the set and the base URL for it), would it make sense to
> stick this into the primary.xml with its own namespace, i.e., add to the
> package tags in primary.xml something like
> 
>   <package pkgid='..'>
>     <version ../>
>     <set:base name="fedora-cds" href="media:/cdrom1"/>
>     .. usual package metadata ..
>   </package>

I really like the above, with the following comments:

We probably want a unique id here as well as name so that CD1 of FC5 !=
CD1 of FC6. Name could then be human readable so we can ask for

Disc 2 of Paul's Extras CD set.

Also I guess we want the media URI to have concept of id and fragment,
thinking about this some a full uri could be described as:

href=media:/ID/Fedora/RPMS/foo-1.2-3.noarch.rpm#3

So within the set I want to encapsulate ID and Fragment/Volume.

I think that works based on:

http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#fragment

Looking at that RFC also has lead me to another example of fragmented
media, that of multipart MIME:

http://www.ietf.org/rfc/rfc2046.txt

> I think a more general purpose remapping mechanism for packages could be
> very interesting for creating 'virtual' repos, i.e. repos that only
> contain metadata and take the actual RPM's from a different place
> entirely. 

I know currently people have been doing that with group data as it's
global, but ideally this would be good.  The only issue I have with this
is at the moment we don't really have a repoid in the repomd.xml - that
is purely done by the client, but referring to via href would be
possible.  Maybe we're really describing supplemental location
information, and set is the wrong name space.

> That would make it possible to create repos for special
> purposes like 'Web Server Installation' or 'Custom app setup' without
> duplicating package storage, creating a mechanism that is similar to
> channels in RHN, but much more flexible.

Sure, I agree that we want something that people can use flexibly.

Paul