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.
pete
|