l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2001 Dec 30 16:58

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Application Upgrade Questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Application Upgrade Questions



It is helpful to know exactly what the two forms of SW installation are
for and what their limitations are. RPM is a package manager, which
that it installs (1) the actual files, (2) a list of all such files
installed, and (3) optinally, some shell scripts that are run before or
after installation or removal. The list of files is the basis of RPM's
'intelligence'---for ex., rpm knows how cleanly upgrade files because it has
that list of everything installed (so it knows what files to delete to
remove the old version) and what script to run to undo any changes that the
install-time script made to the system. All RPMs are expected to handle these
operations properly because that is the design goal of RPM.

The typical 'make install', by contrast, is just a script (the 'install'
target in the Makefile, a script which is executed by make(1) ). That script
does whatever the author of the program wrote it to do---typically calling
install(1) to copy the compiled binaries to $PREFIX/{bin,lib,share}. Make
install DOES NOT write a log of files installed and system changes made to a
central register as a package manager does.

Note that helpful program maintainers include a 'make uninstall' target. You
will need to keep the tarball for the version you installed around to use
this (which is a good practice anyway).

Tarballs containing binaries are the simplest case of all. They just produce
files in the place you specify when running tar. Depending on the flags you
pass to tar, files from tarballs may or may not be installed anywhere on you
machine and may or may not over-write existing files without prompting. If
you delete the tarball, you do not have a list of files installed saved
anywhere. It's a good practice to only extract tarballs of binaries to either
/opt or /usr/local and keep a list of files so installed (e.g., run 'tar tzf
tarball.tar.gz >> /opt/installed-from-tarball.log').

Bob Scofield asked:
> 1)  If you have a program that's been installed by an rpm, and you want
> to upgrade to a new version all you have to do is to get the rpm for the
[...]o

RPM knows how to remove the old version first and then install the new
version if invoked as 'rpm -uvh newpackage.rpm'. (The extra flags give you
progress indicators.) (Or is --upgrade shortened to -u? I can't remember.)

> 2)  Suppose that you have a program that was installed by an rpm, and
> you want to upgrade to a new version, but you want to download a tar
> ball and compile the newer version.  Do you have to remove the older
> program first, or will the compiled version simply over write the old
> rpm version?

Remove the RPM version first ('rpm -e') and then make install.

> 3)  Suppose that you have a program that was compiled, and you want to
> upgrade to a new  version, but you want want the new version to be
> installed by an rpm.  Do you have to remove the older version and
> install the rpm by executing the -i option?  Or, can you just leave the
> older version there and execute the -u option on the rpm?

You probably need to remove the compiled version manually, then you can
install using RPM.

You should not create situations in which RPM's database of installed files
does not correstpond to the filesystem. Example: overwriting binaries in
/usr/bin with make install.

I hope this is helpful.

-- 
Henry House
OpenPGP key available from http://hajhouse.org/hajhouse.asc


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.