On Thu, 6 Apr 2006, Ralf Corsepius wrote:
On Thu, 2006-04-06 at 11:16 -0500, Les Mikesell wrote:
On Thu, 2006-04-06 at 10:55, Mike McCarty wrote:
I also nearly always use --prefix, and install into my home
directory, not to /usr/local. I've got a /home/jmccarty/usr/... tree.
If anything goes bad, I just delete the directories altogether.
There is NO UNINSTALL NEEDED.
This brings up another problem with packaging. Anything I'd
be likely to compile myself these days is probably very
experimental and I might like to have 2 or more versions
to compare them or to have a known-good version if the
latest one blows up. You can do that with many source
bundles with the --prefix option and using explict paths
to execute the programs. How do you do it with RPM packaged
items?
Exactly as you say.
By using different installation prefixes - inside of the rpm.spec.
Or by making the RPM relocatable.
Additionally you'll have to use non-conflicting rpm package names.
Ralf
Everything involves tradeoffs.
For software that installs all in one subdirectory, managing the files
isn't a big deal, whether you use RPM or configure-make-make-install.
The disadvantage to RPM is the need to create one or find one. The
advantage to configure-make is convenience. The advantage to RPM is that
you can test for dependencies.
But software that installs itself in various system directories is another
matter. In that case, you need an uninstall procedure of some sort. For
configure-make, that process is often manual and may run to tens of files
and subdirectories. In addition, RPM will protect you from overwriting
files that belong to other packages, and you still get dependency
management. (For standalone packages, "dependency hell" is usually not
much of a risk unless it reaches into system-level packages. Often,
rebuilding the RPM is enough.)
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
