ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Originally posted by tonyfreeman 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?
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"
Last edited by Dark_Helmet; 09-03-2004 at 12:15 PM.
Distribution: Debian testing 64bit at home, EL5 32/64bit at work.
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
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 :-)
Last edited by tonyfreeman; 09-03-2004 at 03:02 PM.
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.