Bug 182473 - Yum repository for local CD/DVD installation media should be included
Yum repository for local CD/DVD installation media should be included
Status: CLOSED DUPLICATE of bug 188750
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
: 187346 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-22 14:47 EST by Ravi Terala
Modified: 2014-01-21 17:53 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-12 15:00:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ravi Terala 2006-02-22 14:47:02 EST
Description of problem:
The CD/DVD media used to install FC5 should be added as repository location.
This allows faster installation of additional components.

Version-Release number of selected component (if applicable):
Fedora FC5 test 3.


How reproducible:
Easy to reproduce.

Steps to Reproduce:
1. Install FC5 test3 using DVD media.
2. See yum.conf for available repositories.
3. The installation media (CD/DVD) is not present in the available installs.
4. Any "yum install" will check with internet even if the same stuff is
available on a local DVD media.
  
Actual results:


Expected results:


Additional info:
Comment 1 Ignacio Vazquez-Abrams 2006-02-22 14:52:01 EST
What do you propose be done to switch between network and media repos?
Comment 2 Jeremy Katz 2006-02-22 14:54:38 EST
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
Comment 3 Bill Nottingham 2006-02-22 14:56:20 EST
What is the baseurl format for media, in any case? Shouldn't anaconda be the one
to write this?
Comment 4 Ravi Terala 2006-02-22 14:57:18 EST
(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.
Comment 5 Seth Vidal 2006-02-22 14:59:00 EST
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? :)


Comment 6 Bill Nottingham 2006-02-22 15:00:08 EST
Won't the file:/// location change depending on what gnome-mount is doing? :)
Comment 7 Jeremy Katz 2006-02-22 15:01:12 EST
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 :-/
Comment 8 Ignacio Vazquez-Abrams 2006-02-22 15:09:37 EST
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.
Comment 9 Ravi Terala 2006-03-07 08:10:20 EST
(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?
Comment 10 Ignacio Vazquez-Abrams 2006-03-30 07:53:57 EST
*** Bug 187346 has been marked as a duplicate of this bug. ***
Comment 11 Erik Jacobson 2006-04-04 12:21:12 EDT
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.
Comment 12 Erik Jacobson 2006-04-04 15:39:48 EDT
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
Comment 13 Jeremy Katz 2006-04-12 15:00:12 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.