Revision / Modified: Mar. 15, 2002
Author: Tom Berger
Original documents:
http://www.mandrakeuser.org/docs/basics/brpm.html
http://www.mandrakeuser.org/docs/basics/brpm2.html
http://www.mandrakeuser.org/docs/basics/brpm3.html
http://www.mandrakeuser.org/docs/basics/brpm4.html
http://www.mandrakeuser.org/docs/basics/brpm5.html
RPM is short for Red Hat Package Manager. First used by the Red Hat Linux distribution (obviously ;)), it is now the package format of choice for most major distributors: SuSE, Caldera, Conectiva and - of course - Mandrakesoft, to name a few.
What is a 'package', then? A package is an archive: it contains all the
files which belong to a certain application, program library or whatever the
package name indicates. Think of an ZIP or an TAR archive. But apart from this
(compressed) archive, the package also contains control scripts. These control
scripts are read, executed and stored by the local RPM installation and handle
things like installation, deinstallation, status checking, dependencies
etc.
Packages are built by package maintainers using a so-called 'specfile'
(specification file) which determines where the files of a package are going
to be installed to, which other packages are needed by the package in order to
work correctly, what programs to execute before or after installing or
uninstalling a package, but also information on who built the package and
when, a description of the purpose of the content of the package and much
more.
In order to work efficiently, RPM needs to keep track of which packages are installed on a system. This database is located in '/var/lib/rpm'. As you will see, this database also allows you to extract lots of useful information about installed programs.
Among the things RPM and the package maintainer do for you are:
Compiling and patching the program's source code. This is convenient especially for new users. Compiling source code and applying patches requires some advanced knowledge, although it's by no means black magic. But even if you know enough to compile sources on your own, RPM comes in handy when you just can't be bothered with compiling or the sources are large or known to be tricky to handle.
Handling dependencies. In contrast to monolithic operating systems like
Windows, Linux systems can differ from each other pretty much depending on
installation size, intended use of system, personal preferences of the user
etc.
Now instead of equipping all Linux systems with all the necessary files, you
select the files, programs, program libraries you want. When you are about to
install a new program, RPM will check if you've got everything installed
needed to run the program successfully. And what's even more important, it
will prevent you from accidentally removing packages which are essential for
other packages or even your system as a whole.
Providing information on file status. RPM provides you with many possibilities to inquire the status of packages, be they installed or not. You can check new packages for integrity before you install them and check afterward if they have been installed correctly. You can find out which package has been installed when, how much space it takes up, which documentation or configuration files are included, recent changes applied to the package by the package maintainer and more.
Security checks. RPM provides a mechanism to sign packages with a PGP or GPG signature. This way you can make sure that the package has not been tampered with.
Automation. RPM can and is used in many scripts to automate maintenance tasks. It also provides the sound foundation for graphical RPM tools and extensions like 'rpmfind' or Mandrake Linux' own 'urpmi' system.
Clean removal. It just takes one command to remove an RPM from your system. This command will remove everything except for files changed during the installation time of the package (usually configuration or spool files).
Preserve configuration files. The package maintainer can decide how to handle configuration files of older package versions. He can either leave them in place and create the new versions as 'rpmnew' files, or he tells RPM to rename the old configuration files to 'rpmsave' files and put the new versions in their place.
Discrimination between runtime and compile time files. Packages containing program libraries are split in runtime and compile time ('devel') packages. If you don't compile source yourself, you don't need to install the 'devel' packages. Or you can install them when you want to compile some software and remove them again afterward.
Network capability. It doesn't matter to RPM if the packages it is told to operate on are on a local file system, an NFS mount or an FTP server, as long as you provide the full path to the file(s).
Easy rebuilding. Every RPM containing Free or Open Source software stems
from a 'Source RPM' (aka SRPM or 'src.rpm'). This SRPM contains everything
which is needed to build the related RPM(s).
This can be useful if you want to use different compile time options or
simply adept the package to your specific system environment (release, kernel
version, library versions etc), without getting the source yourself, applying
all the needed patches and so forth.
Like every tool, RPM has its limitations:
No automatic resolution of dependencies. RPM will tell you what's missing, but it won't fetch and install it for you. This major limitation can be - at least partly - overcome by using extension tools like Mandrake Linux' 'urpmi' or the generic 'rpmfind' script.
No interactive configuration. Vendor supplied packages usually contain adapted configuration files and post-installation scripts. Interactive configuration steps however must be taken separately from installation (if needed).
No protection from packaging errors. We all make mistakes, and package maintainers are no exception. Incorrect specfiles can prevent a packaged program from running properly after installation. In theory it is even possible to use RPM to intentionally damage a system (since installation has to be done as 'root'). Therefore you should only use packages from trusted parties.
No compatibility guarantee. RPM is used by many Linux distributors and independent persons. Different packaging policies might prevent a package either from installing or the included program from running after installation (e.g. by putting the executable in a different directory than your distribution). Prefer packages from your distributor to those of others.
Optimizations. It is possible to optimize RPMs for a certain type of
processor by compiling the program sources with the appropriate options.
Mandrake Linux does that for the Pentium-class (i586) of processors.
But these compiler options are just one part on a vast array of available
compiling settings.
Usually the packager will try to enable as much options as possible, which
results in bigger - and sometimes slower - executables and big packages with
lots of files. Bottom line: if you want fine tuning, you have to compile the sources yourself.
Although RPM is by no means perfect, it is a very versatile tool, all the more when used in conjunction with extensions like 'urpmi'.
I'm not going to discuss the handling of graphical package managers like Mandrake Linux' Software Manager, GnoRPM or KPackage here. They come with their own extensive online help. Furthermore will understanding the basics of the RPM system enable you to handle all of them.
Check out the Linux Demo and Tutorial Center for animated guides to KPackage and the Software Manager. The official Mandrake Linux 'Installation and User Guide' also dedicates a complete chapter to Package Management with the Software Manager.
The name of an RPM consists of three parts: the archive name, the archive
version number and the version number of the package.
Thus 'mc-4.5.51-7mdk.rpm' means: 'This package contains an archive called
'mc', version 4.5.51. It is the seventh revision of this particular package.'
'mdk' denotes the distribution (not mandatory).
Why an extra number for the package version? Packaging is a complex process. Sometimes the packager may overlook some detail and has to come up with a fixed package. Or maybe he or she just has discovered a way to make the package better. The package version number allows upgrading packages which contain the same version of an archive. Notice that a package version number can consist of two parts, separated by a full stop. This usually signifies a package which has been updated for security reasons.
Sooner or later you will encounter packages like 'mc-4.5.51-7mdk.src.rpm. These are Source RPMs. Unless you know what these are and how to handle them, they are of no use for you.
RPM discriminates between a not-installed and an installed package.
Operations on a not-installed package require the full file name as
the argument to the RPM command, like
rpm -i mc-4.5.51-7mdk.rpm
to install the package 'mc-4.5.51-7mdk.rpm' on the local system.
If you are doing something involving an installed package, however, its archive name is required:
rpm -e mc
erases the package containing the 'mc' archive from the system. This works
because you can't install two RPMs with the same archive name on the same
system.
If you are trying to do something like
rpm -e mc-4.5.51-7mdk.rpm
you will get
error: package mc-4.5.51-7mdk.rpm is not installed
even if the package is installed.
RPM accepts a sackful of options. Thankfully it is pretty obvious from
their names what they do.
Most options come in two flavors: a long option and a short option. The long
option features two hyphens and the full option name, the short one hyphen and
- in most cases - the first character of the full option. Of course you only
have to provide one option form, i.e. either rpm --install
package or rpm -i package.
If the argument to RPM is a file name, you can use globbing patterns to specify a set of files, e.g.:
rpm -i bla*
will install all packages in the current directory which begin with the string 'bla'. Operations which require the archive name, however, do not accept them:
rpm -e *gtk*
error: package *gtk* is not installed
Remember that RPM doesn't care whether not-installed packages are on a local file system or on a remote web or FTP server. Every operation on a not-installed package can be done remotely by supplying the full URL to the package(s):
rpm -qpi ftp://ftp.server.com/RPMS/bla*
gets the descriptions from all packages starting with 'bla' which are located in the 'RPMS' directory on ftp.server.com.
All of these commands require 'root' privileges.
There are two special modifiers used in conjunctions with these options, '--test' and '--verbose' (or '-v').
'--test' only executes the command 'as if': that is you get all the messages RPM usually produces, but the command itself is not executed. This modifier has no short option.
'--verbose' ('-v') increases the amount of output RPM displays on the screen. This is especially useful in case of errors or together with the '--test' modifier. Adding another '-v' ('-vv') increases the level of verbosity even more.
These commands do not require 'root' privileges. Notice that when you are querying not-installed packages, you have to add the '-p' option to the '-q' option.
rpm -q mc
mc-4.5.51-7mdk
Using additional utilities and the somewhat awkward '--queryformat' option, there's almost nothing you can't find out about a package or the local RPM database.
A common problem: you want to check if a package is installed, but you don't remember it's exact name (or are too lazy to type it). Use
rpm -qa | grep -i pattern
This is a so-called pipe with the grep command (the '-i' option makes the search case insensitive). So, a command like
rpm -qa | grep -i xfree
will return a list of all installed packages with the string 'xfree' in them, regardless of capitalization.
Another common problem: which package contains a certain file? Put your Mandrake CD into your drive (let's say it's '/mnt/cdrom') and type
for i in /mnt/cdrom/Mandrake/RPMS/*.rpm ; do rpm -qpli $i | grep filename && echo $i ; done
This for-do loop will return the name of the package which contains filename, if there is such a package on the CD. That's a tad tedious, advanced queries usually should be performed using the Mandrake Linux 'urpm' tools to be introduced on the next page.
If you've cared to read the introduction on the first page, you already know that RPMs are made with the help of spec files. The '--queryformat' option allows you to query each spec file field of any given RPM separately and in any preferred order. Enter
rpm --querytags
to get a list of all valid fields. The formatting is a bit complicated and
best explained by means of an example.
Imagine you are short on disk space and want a list of all installed packages
sorted by size to find out which package would be best to uninstall. This is
what the command (one line) would look like:
rpm -qa --queryformat '%{name} %{size}\n' | sort -n +1 | column -t
Tough one, eh? ;) The first part does all the work: querying all packages
by the 'querytags' 'name' and 'size' only (have to be enclosed in '%{[tag]}').
Since the 'querytags' string contains spaces, it has to be enclosed in single
quotes. The '/n' inserts a line break after each line.
The 'sort' command sorts the output (largest package last) and 'column' makes
two nicely separated columns: names on the left, size in bytes on the right.
As long as you remember the special querytags formatting rules, you should
have no trouble using this option.
You see that you can do a lot of nifty things with RPMs, but the more you want, the more complicated the RPM syntax gets. Other capabilities like the automatic resolution of dependencies or globbing of archive names are missing completely. Time for Mandrake Linux' 'urpm' ...
Mandrake's 'urpm' ('User RPM') - introduced in ML 7.0 - tackles several RPM weaknesses:
'urpm' isn't meant as a replacement for RPM, it is meant to make common RPM tasks easier. In many parts it resembles the package tool the of the Debian GNU/Linux distribution, 'apt'.
This page refers to 'urpm' as of ML 8.1.
The central configuration file is '/etc/urpmi/urpmi.cfg', the flat text data files are located in '/var/lib/urpmi', the log files in '/var/log'.
When you've installed your system from CDs, these will most likely already be indexed by 'urpm'. To add more installation media (other CDs, local directories, remote directories), use 'urpmi.addmedia'. Let's say you have a local 'rpms' directory in your home directory where you keep downloaded RPMs. To add this directory to the urpm database, run (as 'root'):
urpmi.addmedia local file://home/user_name/rpms
'local' is the nick name under which this resource can be referred to in the future. Update the data base with the data from the new 'local' resource:
urpmi.update local
Now the packages in 'rpms' are part of the urpm database and taken into account during all urpm operations. Don't forget to run 'urpmi.update' if the content of that directory changes (the same goes for all resources with non-static content like FTP directories).
Notice that for remote package resources you have to provide the relative path to the Mandrake Linux 'hdlist.cz' file on that server (relative from the directory where the RPMs are, that is) in the 'base' directory. This means you can't add remote resources to urpm unless they provide that dependency file.
To remove a resource from urpm, run (as 'root'):
urpmi.removemedia resource_name
'urpm' consists of a set of tools, each performing a certain task (in contrast to 'rpm', which works entirely via options).
These commands require 'root' privileges.
To install a package available on one of the configured resources, run
urpmi archive
E.g. to install the 'mc' package:
urpmi mc
'urpmi' will check if this package is available and either download it (if it's on a remote resource) or prompt you for the removable medium the package is on or simply install it from the hard disk. If the package needs other packages, 'urpmi' will ask you if it is OK to install these, too. If you don't want to be asked, add the '--auto' option.
In case the archive name you provide is ambiguous, urpmi will print a list of all matching archive names and exit. You can modify this behavior by using the '-a' option:
urpmi -a gtk
for instance will install all packages whose archive names contain the string 'gtk'.
Another useful option is '-p' which allows to filter packages by what they provide. Example: Let's say you know you need the 'libe2p.so.2' program library, but you do not know which package provides that library:
urpmi -p libe2p.so.2
makes urpmi check which package provides that library and install that package, in this case 'libext2fs2'.
Of course, you can also use it to simply install a local package like you would do with 'rpm -U'. Notice that 'urpmi' always upgrades if it finds an earlier version of the package which is to be installed. Sometimes this is not the behavior you want, e.g. when installing a new kernel or when you need two different versions of the same program library. In these cases, you must use 'rpm -i'.
To uninstall packages, you use 'urpme':
urpme archive
If uninstalling the package would break dependencies of other packages, 'urpme' asks if these should be removed, too. If you don't want to be asked, add the '--auto' option. You should only use this option if you are pretty sure what you are doing ...
'urpme' also accepts the '-a' option:
urpme -a gtk
removes all installed packages whose names contain the string 'gtk'.
Another area where the 'urpm' system really shines is querying, since the 'urpm' database does also contain information about packages which are not installed. The 'urpm' query tool is 'urpmf'. 'root' privileges are not required.
urpmf file
lists all packages in its database which contain file.
'urpmf' supports a lot of options which allow to query certain fields of package information. You want to know what packages containing games are available?
urpmf --group Games
How big is the 'pingus' package?
urpmf --size pingus
pingus:size:11026299
What is this package about?
urpmf --summary pingus
pingus:summary:Pingus - A free Lemmings clone
Have a look at man urpmf for more query options.
There's another urpm query command called 'urpmq', which is only of limited interest, though.
urpmq string
lists all known archive names which contain string. Globbing patterns are not allowed.
urpmq --sources archive
tells you on which resource archive is located. This command requires 'root' privileges.
urpmq -d archive lists all packages archive depends on and urpmq -r archive prints the full package name of archive.
Other options are listed in man urpmq.
The urpm system allows you to update your system with the latest security and bug fixes by MandrakeSoft via the command line or even automatically, provided you have added at least one Mandrake Linux mirror to your 'urpmi.cfg' with 'urpmi.addmedia' (actually this is very convenient to do via the Software Manager, so you might want to it at least for this task).
The updating command is very simple
urpmi --auto-select
checks all configured resources for updated packages, lists them and asks if they should be installed. If you don't want to be asked, add the '--auto' option. This option is also convenient when you want you want to run the update via a cron job. Do not forget to run 'urpmi.update' to refresh the resource database.
You can put certain packages on 'hold', i.e. to be ignored by the update command. For this, add the archive names of these packages to the file '/etc/urpmi/skip.list'. For instance, to prevent 'urpmi --auto-select' from installing newer kernel or glibc packages:
kernel
glibc
If you have to provide updates for a larger network, have a look at the 'MandrakeUpdateRobot' package on your Mandrake CD. This package allows network administrators to deploy Mandrake Linux updates over a multitude of clients without much hassle.
An S(ource)RPM does not contain the compiled program, but the sources the
RPM has been built from. You usually only need to bother with them, if you
want to rebuild an RPM because of incompatibilities (see below).
SRPMs are marked by the file name ending 'src.rpm'.
The '-devel-' RPMs contain the so-called 'header' files, i.e. stuff you
need to compile other programs 'against' it. Non-devel RPMs contain the
'runtime' files, i.e. all the files you need for normal operation.
Unless you intend to compile programs for yourself, you don't need '-devel-'
RPMs at all.
'Upgrade' replaces an earlier version, 'installation' leaves previously
installed versions untouched (if possible).
This is quite important when it comes to 'libraries' (these contain code
applications rely on). Different programs may rely on different versions of
the same library. 'Upgrading' would break those programs which relied on the
replaced library version. RPM would not allow you to do this.
It is no problem, however, to have several versions of the same library
installed on your system.
Both refer to configuration files. An '[...].rpmnew' file contains the new
file from the RPM. The original file is untouched.
An '[...].rpmsave' file contains the old version of the file. The original
file has been replaced by the file contained in the RPM.
rpm -qa | less
lists all installed RPMs in the 'less' pager.
By installation date:
rpm -qa --last | less
By size:
rpm -qa --queryformat '%{name} %{size}\n' | sort -n +1 | column -t
less /var/lib/urpmi/compss
In 'pure' RPM, you can create lists by redirecting RPM's output to a file:
rpm -qpi *.rpm > ~/rpmlist.txt
urpmf file
If you are not using the 'urpm' system, use this command:
for i in *.rpm ; do rpm -qpli $i | grep file && echo $i ; done
You can also use the search machine at rpmfind.net. Just enter the name of
the file you are looking for.
Most graphical RPM tools offer a search function, too.
Some file managers like the Midnight Commander (mc) allow you to browse RPMs like directories and to copy files to a directory of your choice.
The 'rpm2cpio' command allows you to convert an RPM into a 'cpio' archive, which can then be operated on with the 'cpio' command.
rpm -F *.rpm
will upgrade all RPMs which are installed and for which the directory contains newer versions.
See previous entry.
Use the '--root=[dir]' option. If you've booted the Mandrake Linux rescue system, for example, you can install RPMs to the Linux system on the hard disk mounted on '/mnt' with
rpm -i --root=/mnt /path/package
Notice that this only works locally, not via a network connection.
rpm -U --oldpackage package
Get the source RPM for this package, usually denoted by '[packagename].src.rpm' and use this command from the 'rpm-build' package to recompile and install it:
rpmbuild --recompile SRPM
If you want RPM to build a new package, too, use
rpmbuild --rebuild SRPM
Notice that this process often requires some 'devel' RPMs to be installed. You will find the rebuilt RPM in '/usr/src/RPM/RPMS/arch'.
If the RPM is incompatible only because of installation path differences, you can either try to 'relocate' it:
rpm -i --relocate oldpath=newpath
or - before you install it - you link the RPMs installation directory to the one preferred by your system, e.g.
ln -s /usr /opt/kde
for SuSE's or Caldera's KDE RPMs.
Add the '-hv' option to get a progress bar. For more text output, use the '-v' or even the '-vv' option.
rpm -i --excludepath path package
excludes all files whose name begins with path.
rpm -i --excludedocs package
doesn't install documentation files. This can be useful for 'devel' packages which come with loads of documentation. May not work with some RPMs
Duh, that would be an article in it's own right ;).
A good introduction can be found in the RPM HOWTO. Still the
authoritative source on this topic is Maximum RPM.
For Mandrake specific information, have a look at the Mandrake RPM
HOWTO.
Sometimes files are provided by multiple packages. If you try to install an RPM which contains files already installed by another RPM, use
rpm -i --replacefiles package
Install RPM 3.0.5 from the ML 7.2 release. This version is the only RPM 3.x version which can handle RPMs packaged with RPM 4.x. ML 8 uses RPM 4, which is backward compatible.
Only 'root' may install, upgrade or remove packages. Use su or sudo.
Notice that only Mandrake Linux 8.0 allows 'urpmi' to be executed by a
normal user. In order to be allowed to use 'urpmi' in 8.0, you have to be
member of the 'urpmi' group. Add your user name to the appropriate line in
'/etc/groups'. You have to be root in order to do that.
'urpme' is only to be executed by 'root'. 'urpmi' will only work for 'root'
when installing single RPMs from directories unknown to 'urpmi'.
RPM only checks its own database for resolving dependencies, not the actual system. So even if you have all the dependencies fulfilled by self-compiled packages, RPM will fail the dependency check. (Actually, I've heard newer versions of RPM do check the actual install base and not only their data base. I'm not sure, though.)
There are two workarounds for this problem:
Create a file in '/etc' called 'rpmrc' and add to this file an entry like this:
Provides: file
file is the name of the self-compiled file (e.g. 'libguile.so.2'). This works because RPM's dependency system works on the basis of files, not packages. An entry like this let's RPM assume that this dependency is fulfilled, even if this file isn't listed in its data base.
You can tell RPM to ignore dependencies by using:
rpm -i --nodeps package
However, this will ignore all dependencies, so you should be sure that all of them are fulfilled. It is very easy to break your RPM data base when using '--nodeps' (or even '--force'). There are absolutely no normal circumstances whatsoever which require the use of these options. Personally, I haven't used these in years.
Install the 'rpm-build' package from the Mandrake Linux CD and try again.
To build or rebuild RPMs, command macros ('/usr/lib/rpm/[arch-]mandrake-linux/macros') are used. From time to time, new macros are introduced. If a spec file contains a call to a macro which is not listed in the current 'macros' file, the shell will try to interpret this macro and inevitably fail with the above error message.
The most straightforward solution to this problem is upgrading to the latest RPM version on Cooker (I don't know if just replacing the 'macros' files would do, experiences anyone?). Another would be editing the spec file in '/usr/src/RPM/SPECS' to edit the offending macro. This however might result in the creation of a broken RPM.
This document addresses solutions/work-arounds to some of the problems I (Kevin Masaryk) have encountered while using 'rpmdrake' (aka 'Software Manager').
'rpmdrake' is a package management tool for working with RPM files. It is actually just a GUI front-end to 'urpmi'. 'urpmi' is the engine which 'rpmdrake' depends upon.
The only documentation available for 'rpmdrake' lies within the Mandrake Users Guide. There is no man page for 'rpmdrake'.
*Note concerning all problems: the operation of 'rpmdrake' doesn't appear to be consistent between each execution; what I mean is that it doesn't always act the same way or present the same data each time it is run. Many of the problems encountered with rpmdrake can be resolved by simply exiting and restarting the program.
Also, you will need to be logged in as 'root' to perform most of the solutions presented here.
For obvious reasons, this is the most severe, and annoying, problem with rpmdrake. This problem has been known to occur even after a new installation of Linux-Mandrake.
The first thing to check is that the rpm database of what's installed on
your system is intact. An easy way to do this is to try using 'gnorpm' or
something similar.
In the unlikely event that you can't find any packages which are currently
installed on your system in 'gnorpm', then your RPM database is probably
corrupted or missing and needs to be rebuilt. Check the man page for 'rpm'
(man rpm) to see how to do this ... or, if you're lazy: it's done
with this command
rpm --rebuilddb
Next, browse the man pages for 'urpmi' to get an idea of how it works. The following is a list of 'urpmi's configuration files, with their descriptions, taken straight from the urpmi(8) man page (edited for grammar):
'/usr/bin/urpmi'
The urpmi executable (Perl script).
'/var/lib/urpmi/list.*'
Contains the list of all packages known by urpmi and their location.
There is one file list per media(*).
'/var/lib/urpmi/hdlist.*'
Contains information about all known packages; it's a summary of rpm headers.
There is one file list per media(*).
'/etc/urpmi/urpmi.cfg'
Contains one line "name" "url" per media.
'/var/lib/urpmi/depslist.ordered
A simple text file containing all dependencies of all known packages.
'/var/lib/urpmi/provides'
A simple text file containing all provides and the list of associated packages
which contain the provides.
'/var/lib/urpmi/compss'
A simple text file containing the list of packages for each Group used.
Have a look at the '/var/lib/urpmi' directory. You shouldn't have any 'hdlist.*' files. If you do, use
urpmi.removemedia
to remove the media or use the brute-force method and just delete them
(not recommended).
Example:
urpmi.removemedia cdrom1
Next, have a look at the '/etc/urpmi/urpmi.cfg' file. This file should
either be empty (since you've lost all your media) or every line should be
commented out (i.e. has a '#' sign in front of it).
Since we want to start clean, use an editor and delete all duplicate lines in
this file. Hopefully, you'll be left with a few commented-out lines relating
to the original installation CDs which you got with Mandrake.
Here's what a 'normal' urpmi.cfg file should look like for a Mandrake 7.2
Complete installation (plus an FTP media I created):
cdrom1 removable_cdrom_0://mnt/cdrom/Mandrake/RPMS
cdrom2 removable_cdrom_1://mnt/cdrom/Mandrake/RPMS2
cdrom3 removable_cdrom_2://mnt/cdrom/RPMS3
cdrom4 removable_cdrom_3://mnt/cdrom/RPMS4
ftp_depot file://home/ftp/RPM_depot/
Now use 'urpmi.addmedia' to add media. Here's an example:
Put CD1 of Mandrake Linux in your CDROM drive.
Type
urpmi.addmedia removable_cdrom_0://mnt/cdrom/Mandrake/RPMS
(That's one line) * Again, if this doesn't work, the brute-force method is just to add the lines in manually and then use urpmi.update name.
After adding all of your media, you should be able to start 'rpmdrake' and have everything back to normal...hopefully ;-).
You'll find the RPMs you've just added via the new media in the Package Groups window on the left. A search for the new RPM(s) will return false until you restart 'rpmdrake'.
If you go to User->Preferences->Add media(button) and select CDROM as
the "Type of media," you are only able to select the name of the CD and a
"CDROM number" identifier.
This may prevent you from using non Mandrake distribution CDROMs with RPMs on
them, such as Red Hat CDs. The reason is that urpmi needs to know the exact
directory which contains the RPMs and 'rpmdrake' may or may not report the
location properly. Your options are to either: select "Local" as the "Type of
media" and enter the full path to the RPM dir, or add the media with
'urpmi.addmedia' (best choice).
The following is a list of the CDs distributed with Mandrake 7.2 Complete and
the location of the RPM dirs on them (relative from mount directory):
Here's how we'd add CD1 with 'urpmi.addmedia':
urpmi.addmedia removable_cdrom_0://mnt/cdrom/Mandrake/RPMS
Try checking your '/etc/urpmi/urpmi.cfg' file for duplicate entries. If you find any, make sure they're commented ('#') out. Additionally, you'll probably need to use 'urpmi.removemedia' to remove the duplicate media offender and 'urpmi.addmedia' to re-add the media.