.TH NEW-PATCHES LOCAL
.\"
.\" format with "nroff -man new-patches.1" or install in /usr/local/man/man1
.\"
.SH NAME
.if \nW .ll +7m
new-patches \- Find Appropriate Patches for RedHat Linux
.SH SYNOPSIS
.B new-patches
.RB [ -v 
.IR #.# ]
.RB [ -m ]
.RB [ -i ]
.RB [ -o ]
.RB [ -e ]
.RB [ -p ]
.RB [ -b ]
.RB [ -u ]
.RB [ -d ]
.RB [ -h ]
.I PATH
.SH DESCRIPTION
.B new-patches
is a shell script which simplifies the task of finding and installing updates
(patches).
Failure to make the effort to find and install updates is a frequent cause
of breakins.  Hopefully this script will greatly decrease the effort required.
(See also \fByum\fP for a more automated option.)
.PP
With various arguments, described below,
.B new-patches
can also tell you which updates you have already applied or which installed
packages you will be replacing (so you can revert if necessary).
.PP
With no arguments,
.B new-patches
figures out which version of RedHat linux you are running, which packages you
have installed, and emits to standard output the URLs of any updates it finds
to those packages.  You could, in theory, (and the author has) just run:
.TP
\&
.B        rpm -Fvh `new-patches`
.PP
and be updated in one fell swoop but there are good reasons you may wish
to split the task into a few steps.  For instance, you may wish to first
document what you are replacing (in case you need to revert\(emsee
.B -i
below)
or you may wish to first copy the new packages to local disk before
installing them\(emsuch as with
.B get-patches
as below.
.PP
Sometimes updates require additional packages (such as crypto libraries) which
you may not have installed.  To test for this case, you can run:
.TP
\&
.B        rpm -Fvh --test `new-patches`
.PP
If there are "failed dependencies:", you must first find
(see \fB-u\fP below) and then install the needed packages
(using \fBrpm -Uvh\fP), or else manually remove (from the output of
.BR new-patches )
the URLs for those patches which have unsatisfied dependencies.  Similarly,
edit out any other patches you're not ready to install (such as
a new kernel\(emsee warning below), before feeding the list to
.BR rpm :
.TP
\&
\fBnew-patches\fP > \fItmpfile\fP
.br
edit \fItmpfile\fP
.br
\fBrpm\fP `\fBcat\fP \fItmpfile\fP`
.PP
If you're on a slow network, or if you prefer to have a copy of all
the RPMs you're going to install before installing them, you can use
a companion script:
.B get-patches
to download the RPMs to your current directory and then install them:
.TP
\&
\fBget-patches\fP `\fBnew-patches\fP`
.br
\fBrpm -Fvh *.rpm\fP 
.PP
You can override the default URL
.B new-patches
uses as a source of updates either on the command line by specifying a
.I PATH
argument or with the
.B $REDHAT_UPDATES
environment variable.  Both can be either a \fBftp://\fP URL or a path to
a local directory (anything you can list with \fBls\fP).  See also
BUGS below for why you may need to do so.
.PP
The following command-line switches are implemented:
.TP
\fB-v\fP \fI#.#\fP
If you don't specify \fBPATH\fP or \fB$REDHAT_UPDATES\fP, and you just
want to change the OS version number in the default URL for updates,
-v will do that.  Useful, for example, on a 6.1 system to see which
6.2 updates may be available.  (Because, alas, RedHat doesn't always put
them in both places).
.TP
.B -m
Use the main (often overloaded) sites instead of a mirror.  By default,
\fBnew-patches\fP now uses a mirror site, partly in hopes it is faster and
partly because the main sites only offer updates via HTTP (not FTP).
HTTP support in \fBnew-patches\fP requires \fBlynx\fP which may not
be installed on some systems.
.TP
.B -i
Print the installed packages which need replacing instead of the replacements.
If you save this list, you will know what packages to revert to if you
are unhappy with the upgrade.
.TP
.B -o
Reverses the "newness" test.  If you give a PATH or URL to the
RPMs which comprise the stock RedHat release of your OS version,
this will tell you which RPMs are older there.  If used with -i above,
shows what is installed replacing what was older there.
.TP
.B -e
Replaces the "newness" test with an equality test.  Normally, newness
is determined by comparing components of package names.  Much effort was
spent trying to get this right but it can happen that a new package has
a name so dissimilar from the old that the test fails.  -e will cause
.B new-patches
to output any package which is a different version.  The user must then
determine which are actually newer.
.TP
.B -p
Toggle
.BR ftp 's \ passive
mode.  URLs beginning with \fBftp://\fP are listed with your system's \fBftp\fP.
The invocation of \fBftp\fP should cause it to use "passive mode" (which is
desirable for those behind firewalls).  If you have trouble with passive mode,
you can try toggling it on/off with -p).
.TP
.B -b
Print bare package names (do not prepend the PATH or URL).
.TP
.B -u
List packages at path (or URL) \fINOT\fP installed on your system.  This
may be useful for seeing what else is available on your distribution CD or
finding URLs for additional packages which may be required by updates
to existing packages.  You can even use:
.br
\fBrpm  -qp --filesbypkg `new-patches -u` | grep\fP \fI/foo/bar\fP
.br
to search for file \fI/foo/bar\fP in the uninstalled packages, if it
isn't clear from the package names which package contains a file you need.
.TP
.B -d
This flag turns on debugging output for the newness comparison.
.TP
.B -h
Prints the usage instructions from the beginning of the script.
.SH WARNINGS
\fIBEFORE YOU UPGRADE YOUR KERNEL, BE SURE YOU HAVE A CURRENT BOOT FLOPPY!\fP
You can make one with
.BR mkbootdisk .
The time I updated 87 packages (including a 2.2.16 kernel)
on a fresh 6.2 system in one fell swoop
I was glad I made a boot floppy first because I had to boot the floppy
and run
.B lilo
manually before the system would come back up properly.
\fIWHEN INSTALLING NEW KERNELS, IT IS SMARTER
TO INSTALL A NEW ONE WITH \fBrpm\ -i\fP AND LATER
DELETE THE OLD ONE WITH \fBrpm\ -e\fP RATHER THAN DO BOTH AT ONCE WITH
\fBrpm\ -F\fP).
.PP
I've noticed that sometimes patches intended for both 6.2 and 6.1 aren't
copied into the redhat 6.1 updates directory.  If you're running 6.1, you
may still need to run this against the 6.2 updates directory and manually
see what may-or-may-not be relevant (try -v 6.2).
.PP
Packages are sometimes renamed, so you may not notice that a new package
is relevant to your installation.  In these cases, it is left to you to
discover that these new packages exist.  One place to keep up-to-date on
such things is http://www.redhat.com/errata
.SH BUGS
Times change.  Redhat is no longer providing updates for some of their
older (but still viable and widely used) releases.  For a while, those
will be supported by the "Fedora Legacy Project" so,
\fBnew-patches\fP will now, by default, look there for updates to those
versions.
.PP
Because both Fedora and Fedora Legacy are currently only offering updates via
HTTP, \fBnew-patches\fP now also speaks HTTP, however that support is built on
\fBlynx\fP, which must now also be installed if those sites are used.
That's one reason that, by default, \fBnew-patches\fP now uses FTP
mirror sites (unless the \fB-m\fP flag is used).
.SH AUTHOR
Corey Satten, corey\ @\ cac.washington.edu, 02/02/01
.br
See \fBhttp://staff.washington.edu/corey/tools.html\fP for the latest version.
.SH "SEE ALSO"
rpm(8), get-patches(local), mkbootdisk(8), yum(8)
.br
\fBhttp://fedora.redhat.com/download/mirrors.html\fP
.br
\fBhttp://fedoralegacy.org/download/fedoralegacy-mirrors.php\fP