actually rename

1 files changed, 396 insertions, 0 deletions

diff --git a/pod/8/urpmihowto.pod b/pod/8/urpmihowto.pod
new file mode 100644
index 00000000..1eb525d1
--- /dev/null
+++ b/pod/8/urpmihowto.pod
@@ -0,0 +1,396 @@
+=head1 NAME
+
+urpmihowto - urpmi Advanced How-To
+
+=head1 Basic notions
+
+=head2 Packages and media
+
+The urpmi suite of tools has for main purpose to download and to install
+RPM packages easily.
+
+Software packages often depend on each other; urpmi is able to recognize
+those dependencies, to download missing required packages as needed, and
+to remove conflicting packages if it needs to.
+
+urpmi gets the list of available RPMs, and the RPMs themselves, from a
+B<media>. Roughly speaking, a media is described by a name and by a
+location, specified by an URL. Currently supported media types are: local
+drives, removable drives (such as CDs), ISO images, and networked media
+via different protocols (http, ftp, ssh and rsync). NFS mounted
+directories are treated like local drives.
+
+=head2 Installing and updating RPMs
+
+The tool used to install RPMs is urpmi. Its basic usage is as follows:
+
+    urpmi <list of package names>
+
+That prompts urpmi to fetch and install all packages and their unmet
+dependencies from the media you have configured. In the process, urpmi
+might ask a few questions. Notably, if some packages need to be upgraded,
+or if some new (unspecified) packages should be installed, it will ask for
+confirmation. If some packages need to be removed (due to conflicts with
+the requested packages), urpmi will ask for confirmation as well. In some
+cases, urpmi will also propose a choice between different alternatives,
+usually proposing the "best" package as a default.
+
+Another very useful mode of action for urpmi is to ask it to upgrade all
+packages to the latest version found on the media. This is done by
+
+    urpmi --auto-update
+
+urpmi can also help installing RPM files directly. Instead of using
+C<rpm -i foobar.rpm>, you can pass the path to the rpm file to urpmi: it
+will then try to resolve the needed dependencies.
+
+Useful options to urpmi include :
+
+=over 4
+
+=item --auto
+
+automatic mode: urpmi will not ask questions and always select the default
+choice.
+
+=item --test
+
+tests the installation of packages, but do not actually install anything or
+modify the system.
+
+=item --media I<media1,...,mediaN>
+
+Use only the specified media, instead of defaulting to all available
+media. You can also specify a substring of media names, and urpmi will
+select all media that contain this substring. (For example,
+
+    urpmi --auto-update --media updates
+
+will search updates from all media that have "updates" in their name.)
+
+=back
+
+See the urpmi(8) manpage for the complete reference of all options that
+urpmi supports.
+
+=head2 Removing RPMs
+
+The tool used to deinstall RPMs is urpme. The command
+
+    urpme <list of package names>
+
+will attempt to remove all listed packages, plus the packages that depend
+on them. It will refuse to uninstall "important" packages (that is, the
+ones that are part of the base system.)
+
+See the urpme(8) manpage for the reference of all options urpme supports.
+
+urpme will detect packages that are no longer used: for example, libraries
+that no application requires. To remove them, use B<urpme --auto-orphans>
+
+=head1 Media management
+
+=head2 Adding media
+
+urpmi is usable only when you have defined some media. Usually the OS
+installation procedure configures a predefined set of media, which
+correspond to the installation method you've selected: that might be
+installation CDs, or an HTTP or FTP server if you installed from a
+networked mirror, and so on. But you might want to add media yourself.
+For that, you should use the urpmi.addmedia program. Its usage is as
+follows:
+
+    urpmi.addmedia [options] <name> <url>
+
+In this synopsis, C<< <name> >> is the name of the new media,
+C<< <url> >> the URL where the RPMs are to be found.
+
+Supported URLs can be C<http://>, C<ftp://>, C<rsync://>, C<ssh://> (this
+will use rsync over ssh), C<file://>, and C<cdrom://>. If the media requires
+authentication, you can use the usual URL syntax:
+
+    <scheme>://<login>:<pass>@host/path
+
+Those credentials won't be stored in any world-readable file.
+
+In some cases, if your media points at an external HTTP or FTP server, you
+might want to use a proxy to access it. This is possible by using the
+C<--proxy> and C<--proxy-user> options (the second one in case of your
+proxy requires authentication.)
+
+=head2 Removing media
+
+This is straightforward; to remove a media C<foo>, simply use the
+command:
+
+    urpmi.removemedia foo
+
+=head2 Updating media
+
+Some media never change; this is the case, for example, for CD-ROMs and
+the like. However, some other ones -- typically updates -- grow; new RPMs
+are added to them, and old ones are removed. Thus, before using them, from
+time to time, you should instruct urpmi that their contents might have
+changed.
+
+To do this, use the urpmi.update program. You can either update all media:
+
+    urpmi.update -a
+
+or update only media specifically named:
+
+    urpmi.update updates-one updates-two
+
+=head2 Creating your own media
+
+The easiest way to create your own media is to let urpmi.addmedia do it.
+However, this will work well only if you have a small number of rpms,
+stored on disk or on a shared NFS mount. To do that, assuming that your
+RPMs are under a directory /var/my-rpms, simply enter the command:
+
+    urpmi.addmedia my-media /var/my-rpms
+
+However, to create media containing a large number of RPMs, or to be put
+on a shared server, you'll need to use the gendistrib tool. It comes in
+the C<rpmtools> package. It is able to generate a mirror tree for one or
+several media.
+
+A typical media repository, under a root directory F</ROOT/>, has the
+following structure: (here, we have two media, named C<first> and
+C<second>)
+
+    ROOT/ - media/
+            |- first/
+            |   `- media_info/
+            |- second/
+            |   `- media_info/
+            `- media_info/
+
+The RPMs are place in the C<first> and C<second> subdirectories.
+Repository metadata is contained in the top-level F<media_info> directory.
+Per-media metadata are contained in the F<first/media_info> and
+F<second/media_info> subdirectories.
+
+Per-media metadata consists in an C<hdlist.cz> file, that contains the
+gzipped headers of the RPMs in the media, a C<synthesis.hdlist.cz> file,
+much smaller than the hdlist and that contains only the information
+necessary to urpmi to resolve dependencies, and optionnally a C<pubkey>
+file if the RPMs are signed (so urpmi can check that the RPMs it downloads
+are signed with the key associated to this media.)
+
+Before using F<gendistrib>, you must create a file F<media_info/media.cfg>
+to describe this media repository. The syntax of this file is reminiscent
+of F<.ini> files. It contains one section per media: for example,
+
+    [first]
+    hdlist=hdlist_first.cz
+    name=First supplementary media
+
+Here, C<first> is the directory name, C<hdlist_first.cz> is the name of
+the hdlist file that will be created (it must end with C<.cz>), and
+C<name=> gives a human-readable descriptive name for the media.
+
+Then, you can run gendistrib. It should be passed the F</ROOT/> directory as
+parameter. It will then generate the hdlist and synthesis files and all
+other files needed for proper repository operation.
+
+For further information, see the gendistrib(1) manpage.
+
+=head1 Searching for packages
+
+=head2 urpmf
+
+urpmf is a grep-like tool for the urpmi database (the database of all RPMs
+in the media). By default, it will search through the file names contained
+in packages, but a variety of options allows to search through package
+names, provides, requires, RPM descriptions, etc. (or several of those at
+once.)
+
+For example, to find all packages that begin with "apache-" :
+
+    urpmf --name '^apache-'
+
+(the ^ being the beginning-of-line anchor used in standard regular
+expressions.)
+
+To find all packages that contain files whose pathname includes
+/etc/httpd.conf.d :
+
+    urpmf /etc/httpd.conf.d
+
+To find all packages that provide "mail-server", with their version and
+release number (-f) :
+
+    urpmf --provides -f mail-server
+
+See the urpmf(8) manpage for more examples and the list of all options.
+
+=head2 urpmq
+
+urpmq is a tool to query the urpmi database. It has several modes of
+operation. Here are a couple of useful uses.
+
+    urpmq -i package
+
+will list the information for that package (like C<rpm -qi> would do for
+installed packages.) The C<--summary> option is similar, but gives only
+one-line concise information.
+
+    urpmq --sources package
+
+will give the URL from which the package can be retrieved.
+
+    urpmq --requires-recursive package
+
+will give the list of all RPMs that are required by the specified package
+(recursively).
+
+Inversely, the command
+
+    urpmq --whatrequires package
+
+will give the list of all RPMs that require the specified package.
+
+See the urpmq(8) manpage for the list of all options.
+
+=head1 urpmi-parallel
+
+urpmi-parallel is an add-on to urpmi that is useful to install packages on
+a network: it will run an urpmi command in parallel on a specified number
+of hosts. In more detail, the machine you run the command on (the
+"server") tests its result on each machine in the group in turn (the
+"clients"), downloads all necessary packages for all machines in the
+group, distributes the appropriate packages to each machine, then calls
+urpmi on the machine to do the actual installation.
+
+urpmi must be installed on all client machines, but it is not necessary to
+have media defined on these.
+
+To use it, follow those steps :
+
+=over 4
+
+=item *
+
+make sure you can ssh from the server to each client machine as root (you
+can use ssh-add on the server host to avoid entering your passphrase
+and/or password many times).
+
+=item *
+
+install urpmi-parallel-ssh and/or urpmi-parallel-ka-run on the server
+machine. The first plugin uses plain ssh to distribute commands to other
+hosts, the second one uses ka-run, an efficient parallelization method on
+top of any remote shell (rsh or ssh), adapted to clusters.
+
+=item *
+
+Edit /etc/urpmi/parallel.cfg to look something like this:
+
+    mynetwork:ssh:host1:host2:host3
+
+On this line, C<mynetwork> is the name of the alias you'll use to specify
+the network to urpmi, C<ssh> is the install method (to use C<ka-run>, look
+up the entry for /etc/urpmi/parallel.cfg in urpmi.files(5)), and hostN are
+the hostnames of all clients on your network. You can put C<localhost> in
+this list.
+
+=item *
+
+Run the urpmi command : for example, to install "package_name" :
+
+    urpmi --parallel mynetwork package_name
+
+=back
+
+=head1 urpmi.recover
+
+urpmi.recover is a tool to help management of RPM rollbacks. One rarely
+used feature of RPM is that it can "repackage" the RPMs it deinstalls
+(either because they are upgraded to a newer version, or because they are
+plainly erased), and then reinstall the repackaged RPMs, thereby restoring
+the system to a previous (hopefully more stable) state.
+
+urpmi.recover has three main functions:
+
+=over 4
+
+=item define a checkpoint
+
+C<urpmi.recover --checkpoint> is used to define a point in your system
+that you consider stable, and to start storing info that will enable you
+to rollback to this state (or to any later state).
+
+=item list installations you've done
+
+C<urpmi.recover --list date> is used to list chronologically all
+installations and upgrades on your system up to the specified date. The
+output format gives them grouped by installation transactions. (This
+option has two variants, C<--list-all> and C<--list-safe>.) Here are some
+examples :
+
+List all installations made during the last day :
+
+    urpmi.recover --list '1 day ago'
+
+List all installations since 7th february 2006 :
+
+    urpmi.recover --list 2006-02-07
+
+List all installations since the checkpoint :
+
+    urpmi.recover --list-safe
+
+Lists all installations and upgrades known to the RPM database :
+
+    urpmi.recover --list-all
+
+=item perform rollbacks
+
+C<urpmi.recover --rollback> is used to roll back installations and
+upgrades to a previous point in the past (at most until your checkpoint.)
+It has two variants :
+
+To roll back until a specified date :
+
+    urpmi.recover --rollback <date>
+
+The date can be a duration (for example "2 hours ago") or a date given
+in YYYY-MM-SS hh:mm format.
+
+To roll back a specified number of transactions :
+
+    urpmi.recover --rollback <number of transactions>
+
+In both cases, be careful not to rollback beyond the checkpoint!
+
+=back
+
+Once you've defined a checkpoint, when you use urpmi, urpme or directly
+rpm to install or remove packages, the older packages will be stored in
+/var/spool/repackage. You thus must make sure you have enough space on
+this partition to store all repackaged RPMs.
+
+Technically, defining a checkpoint is equivalent to writing a file
+/etc/rpm/macros.d/urpmi.recover.macros that overrides the rpm macros
+used to set up the repackaging functionalities of rpm. You can change
+C<%_repackage_dir> there if you want to, if you don't want to store
+repackaged RPMs in /var/spool/repackage.
+
+If you want to disable the repackaging functionality and clean up the
+repackage spool, use C<urpmi.recover --disable>. Warning: rollbacks won't
+be possible anymore.
+
+=head1 Restricted urpmi
+
+urpmi has a "restricted" counterpart: rurpmi. It is similar to urpmi, but
+has a stripped-down set of features. It's intended to be used by users
+without root privileges, but with sudo rights on it, preventing any abuse
+of this tool to compromise the system.
+
+Its syntax is similar to the one of urpmi, but it disallows installing
+arbitrary RPMs: those are forcibly downloaded from a registered media.
+A number of dangerous options, listed in the rurpmi(8) manpage, are also
+forbidden.
+
+=cut