Program management with --prefix= quesiton.
 

Whenever I compile and install programs I mostly use the "--prefix=/usr/local" or on some occasions I use "--prefix=/usr" (depending on the software).

I'm working in a new office where programs are compiled and installed with a "--prefix=/usr/local/program_name-version" I'm wondering about some good reasons NOT to install programs this way.

One thing I can think of is:
1. You have to alter your $PATH, $MANPATH, $LIBPATH and other environment variables to point to the new install. What are the other environment variables?

Please respond with your comments. I'd like to make a case to the other fellow about using "--prefix=/usr/local".

I just comment the $LIBPATH variable, it is not a common environment variable, it dos not exist on my slackware system.

To add a custom library directory I have to add its path in /etc/ld.so.conf and run ldconfig after that to take change in account

Re: Program management with --prefix= quesiton.
 

Not entirely true. You can do that, but you can also make symbolic links from the appropriate directories (/bin, /usr/bin, etc.) point to the newly installed software (/usr/local/program_name-version/bin/some_prog_file). If you keep the programs/libraries separate like this, then it's a convenient form of indirection. That is, you upgrade to a newer version, change the symbolic links to point to the newer version, and your done; completely transparent change to the user. If upgrading, you encounter any problems, have the links point back to the previous version.

You can't do that with --prefix=/usr/local. At least, most of the software I have installed wants to put itself in the same directory as previous versions. So they overwrite the older version. Or, even worse, they get mixed up, and you end up having disk space consumed by unneeded files. By sectioning them off, you get rid of all the files (guaranteed), with "rm -rf /usr/local/program_name-version"

OK ... sounds good so far
 

Thanks for the notes ... brings up a good point about how easy it is to uninstall software and keeping two or more versions using the /usr/local/program_name-version method.

So ... If he does the following:

1. Download the tar.gz (tar.bz2) into /usr/share/src/
2. uncompresses and untars
3. ./configure --prefix=/usr/local
4. make
5. sudo make install

.... then all of the manpages, libraries, configuration files, executable binaries, etc are all put in the correct and logical places to function properly. I need to do nothing but sit back and laugh, drink wine, play with the dog, code on other projects, etc ;-)

As for the uninstall -- sometimes a Makefile has an uninstall option .... that way one can cd into the compile directory and type "make uninstall". I'd have to hang on to that directory of information so that I can uninstall sometime in the future. So I guess I could write a script that will tar and gzip everything in the /usr/share/src/ directory if there is enough to fill a CD, write the information to CD and then clean out everything. If I need to do an uninstall, I can find the CD, put the source code back and type "make uninstall".

Are there any other points about using --prefix=/usr/local that I can note?

Thanks for your input guys and gals :-)

--Tony

I'm not trying to be difficult... I promise :)

Like you said, "sometimes a Makefile has an uninstall option." So there are times when software does not have it. To uninstall that software the /usr/local administrator would need to decipher the Makefile to determine what files were installed, and that's not always easy. The /usr/local/program_name administrator would still only need to delete the directory.

Also, for the uninstall to work properly, you must remember to apply all the patches to the source code, because there is the possibility that a supporting file is created as part of a patch. That complicates the nature of the uninstall. The program_name admin still only has to delete the directory. The /usr/local admin stores the source on CD, but patches come out at random times. That requires re-extracting the source, applying the patch, and re-archiving it (using another CD perhaps).

There is something I did not mention earlier that is a drawback to the program_name method. If the Makefile makes changes to pre-existing configuration files, that poses a problem, because the administrator has to manually apply those changes. This is a fairly rare occurrence, but it is possible.