What do you propose be done to switch between network and media repos?

Eventually, we want to provide some of this functionality at least for the
various higher level tools (pirut/pup/system-install-package), but more work
needs to be done on pushing some of the things for this down to the yum level

What is the baseurl format for media, in any case? Shouldn't anaconda be the one
to write this?

(In reply to comment #3)
> What is the baseurl format for media, in any case? Shouldn't anaconda be the one
> to write this?

I think it should since it knows the location of installation media.

what things are you thinking of being needed to do this? The specific cases I
know of are:
 media change commands


is there anything else I've forgotten or never knew? :)

Won't the file:/// location change depending on what gnome-mount is doing? :)

More of the split transaction stuff needs to be pushed down, and yes, it's
likely that there will have to be some interface specific glue.  Unfortunately,
I'm not sure if there's a sane way to handle generically for command-line/API
yum :-/

What might be nice is some way for a package manager to scan all removable media
on a system for a repodata directory in the root and then add that location as a
repo on-the-fly.

(In reply to comment #7)
> More of the split transaction stuff needs to be pushed down, and yes, it's
> likely that there will have to be some interface specific glue.  Unfortunately,
> I'm not sure if there's a sane way to handle generically for command-line/API
> yum :-/

What are the chances that this bug would be fixed for FC5?

*** Bug 187346 has been marked as a duplicate of this bug. ***

One thing I was playing with the other day was a small hack to pirut to take
a command line argument pointing at an alternate yum.conf.

I may have a need in the future to bundle stuff not part of the base
distribution on to a cd.

I thought I could have the hacked pirut sit on the CD.  The user could run a
INSTALL script that fixes up the paths in a temporary yum.conf to point the
repo on the CD itself.  One of the packages could then lay down the real
repos in to /etc/yum.repos.d to get the user positioned for future updates
to what is on the CD.  Doing it this way would mean the hacked pirut 
command wouldn't need to be installed on the system because valid repos
would exist after installation.  This could potentially get me by until a 
helper and/or repository config piece is implemented.  I just thought I'd
share this in case someone finds it useful for some reason.  I've only
take this as far as looking at alternate yum.conf's, I haven't tried running
a hacked version from the CD yet.

Update for Comment #11.

FWIW - I think I proved the concept.  I created an ISO image with the pirut
that is modified to look at optional yum configurations.  I fired it off with
an install script.  The script fixes up the PYTHONPATH variable to point at the 
modified pirut on the CD first.  The install script also constructs the 
temporary yum.conf pointing at the CD itself (deriving the path from
what the user supplied for the command.. ./INSTALL would look at pwd,
/mnt/INSTALL would use 'dirname', etc).  

Seems to work ok.  So I'll file this in my back pocket if I need it before pirut
gains some of this functionality. -Erik

Erik -- this will really only work for single cd things.  If it has to split
across more than one CD, then things start to work less well :/  Also, instead
of having your own version of pirut itself, it might make more sense to just
copy a repository pointing to a mountpoint into /etc/yum.repos.d and then remove
the file after running pirut.

Also, I'd be okay with some command-line option handling for things like
enable/disabling repos or pointing to a different config file, though.  Feel
free to include them in separate bugs. :)

Going to close this bug as a dupe of the bug I filed for tracking of the real CD
support for pirut.

*** This bug has been marked as a duplicate of 188750 ***