l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
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

On Wed, 22 Nov 2000, William Kendrick wrote:

> 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
> > newer version and execute the -u option.  But how do you upgrade a
> > program that had to be compiled?  Do you have to remove the program
> > before compiling and installing the newer version?  Or, will the newer
> > version simply over write the older version when it is installed?
> It all depends on the person who made the application. :)
> But yes, usually a "./configure && make && make install" will just
> overwrite the old version.
and a great counter example would be when sdl went from .9 to 1.0.  it went
from installing to /usr/lib to the more sane /usr/local/lib.   it was a
problem because on most people's systems, the sdl-config that pointed to the
old version was higher up in the person's $PATH.  it took me a while to
figure out what was happening.
> > 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?
> Danger, danger!

yes, i agree.  there are a couple of dangers here.  you certainly want to
uninstall the rpm.  if you see warnings about broken dependencies, then you
might want to tread lightly.

distributions tune their applications to expect certain things in certain
places.  the prime example is debian.

i think it's debian's policy to never install anything into /usr/local.
at least, that's what their package maintainer's guide says.  yet SDL
installs into /usr/local by default, and all the SDL libs that are
required, by bill's games for example, expect SDL's static libs to be in
/usr/local.  you might have a conflict if you installed debian's SDL
but wanted to install your own sdl_net or sdl_mixer.

it can definitely be done, but you'll have to rely on:

1- intuition and experience.  even bravery.
2- little bit o' luck
3- your competancy in certain things like strace for finding which libs
        aren't being found and ln to link them into where the prog is expecting
        them to be.  :)

certainly, it wouldn't hurt trying to uninstall the rpm and install the
tarball.  if you don't get any error msgs when you uninstall the rpm, then
you're prolly going to be AOK.
> > 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?
> I believe you need to do an "-i"nstall, since RPM doesn't know about
> .tar.gz's.

yup.  rpm has no concept of what tarballs were installed onto the system.
can't do -U.  (i think it's capital U).

> (That's why it's dangerous above... you have libXYZ 1.2
> and install 2.5 as a .tar.gz, then you try to install App123 and
> it requires "libXYZ 2.0 or higher".  Since the RPM database THINKS you have
> 1.2 still, you'll need to force the thing to install, which could be
> troublesome)

i think half of lugod just smiled when they read this.  :)

bob, it takes a couple of bad mistakes to really get some kind of intuition
about whether you should blow away an (rpm/tarball) and replace it with a
(tarball/rpm).  have fun and experiment.  don't do anything that makes you
uncomfortable.  if you want to take a risk, you can always --nodeps (or is
it --no-deps or --force?) the issue.


LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.