patches (was Re: linux security)
merritt at u.washington.edu
Wed Jan 22 22:22:37 PST 2003
On Wednesday 22 January 2003 21:59, Jesse Keating wrote:
> On Wednesday 22 January 2003 21:55, Ethan Merritt uttered:
> > You mean like 'rpm -i' (for install) rather than 'rpm -U' for
> > (upgrade)?
> This won't work. The reason is that the rpm has files that belong in
> a certian place. When a new version of the package comes out, the
> file names are the same. So, until you figure out a way to have
> newer and older files occupy the same name/space, this can't happen.
Actually in the most comon case, of wanting backwards compatible
shared libraries, it works just fine. Say you have libfoo-1.0.1 installed,
and you want to install version 1.0.2 without breaking programs that
explicitly linked to libfoo-1.0.1. You can just install the new version,
leaving both /usr/lib/libfoo.so.1.0.1 and /usr/lib/libfoo.so.1.0.2 in place.
By convention on distros I am familiar with (mostly Mandrake), the
files subject to being overwritten are maintained in a separate and
parallel rpm called libfoo-devel-1.0.2. Installing or upgrading that one
would create the symlinks
libfoo.so.1.0 -> libfoo.so.1.0.2
libfoo.so.1 -> libfoo.so.1.0
libfoo.so -> libfoo.so.1
But the neat thing is that this is OK anyhow, even though the older
symlinks are replaced. Pre-linked programs will still find the old version
of the shared library by its "real" name, and programs linked in the
future will link against the new version by virtue of the symlinks.
Agreed that in the case of actual executables, rather than libraries,
you need to use some variant of the --prefix or --relocate flags.
But in my experience so far this is still relatively straightforward.
Maybe not all the distros are equally good about making sure their
rpm contents are relocatable
Ethan A Merritt merritt at u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195
More information about the Linux