Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
Just to compare notes (when learning, don't you sometimes want to compare your methods against how others do it. I do.)
How much is
to be used. and, what for?
I ask because I'm contemplating compiling and installing Perl 5.8.6 into /usr/local/bin
My experience has reached this point due to sufficient conflicts experienced on various distros in the past.
Such conflicts arose from what I needed to do with Perl and how I formerly attempted to achieve that end.
For example, if use the cpan to install additional modules onto the /usr/bin/perl can sometimes be problematic evidently due to /usr/bin/perl usually is a distro specific Perl which often may have somewhat differences than the cpan perl compiled from source.
Is it common practice to not disturb the /usr/bin/perl (it's needed for a lot of a distro's system maintenance) AND to also have Perl the way that I want with the cpan modules that I want by compiling/installing the Perl from sources, install into /usr/local/bin and use corresponding shebang line in my scripts.
The compile/install of perl I've done it three times already. It always works. Except on a Suse I first had to install gcc and another development thing and then compile/install.
it's just that I don't know what is a common practice (how others commonly deal with the issues that I've expressed herein). It seems weird to me to need two Perls but maybe it's the way to go due to what I need?
Most distributions don't put anything in /usr/local. I always install anything that I'm installing outside of the distibutions package management system in /usr/local. You want to be careful you don't break dependancies by replacing a distribution provided library/program.
In the few cases I've seen where a distibution did use /usr/local as the prefix for somethings I just pick another place like /opt/local or something like that.
When I compile/install things myself outside of my distribution provided package management tool I use /usr/local as the prefix for the install. Libraries go in /usr/local/lib, includes in /usr/local/include, binaries in /usr/local/bin, docs in /usr/local/docs, ect. ect.
If you want to make sure you use the stuff in /usr/local/bin by default then simply put in in your PATH before /usr/bin.
/usr/local does actually serve a purpose. /usr/local is supposed to be used for the local drive. It doesn't really matter to many people on this site since they use their linux boxes as PCs, but many Unix systems actually serve terminals. the local drive of the terminal (if it has one) is usually mounted at /usr/local
So, from what's been said, it appears that I had possibly messed up a dependency (or similar ie caused a problem) by attempting to customize (use the cpan on) /usr/bin/perl
Since I want to use the cpan lots in order for adding modules onto my perl then it appears best to not attempt modification of /usr/bin/perl but instead to compile/install perl from the cpan source code do so into /usr/local/bin/perl and then when i use the cpan to do so on this /usr/local/bin/perl and not mess with the other perl at /usr/bin/perl
And it appears that what I've shared herein is commonly accepted method when the need as you say requires something that is not distro specific (the cpan is not distro specific) the cpan is for perl but it might conflict with dependencies if used on a distro specific perl at /usr/bin/perl
Because a distro won't touch /usr/local, it even makes sense to install this hierarchy in it's own partition. This would allow you to keep programs and libraries you installed from tarballs yourself even if you decide to reformat and re-install a new distro.
I do wonder if you want /usr/bin to precede /usr/local/bin in your $PATH variable, just in case that the distro's version needs to run by default.
According to the Filesystem Hierarchy Standard, "the /usr/local hierarchy is for use by the system administrator when installing software locally." I'm not certain what they mean by locally however, because two lines later it states "It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr." Also "locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr."
Since you said you want to retain the distro's version of perl, you are not upgrading or replacing, to /usr/local is where it needs to go.
However, I'm still not certain what the standard means by "locally installed" since they state that it may be shared by a number of hosts.
I know it is not uncommon to have /usr/local be an nfs mount to a local server containing applications and libraries you want everyone to be able to use. I have seen that setup in several offices I have worked in. In those cases I always put my own stuff in /opt/local instead of /usr/local.
As for the path issue, if you don't change the path so that /usr/local/bin comes first that be aware any programs that exist in both will run the distibutions version and not your own. It should be reasonable to change your users path order, but I wouldn't neccesarily change the path order for the default profile.
Oh ya... be careful about leaving /usr/local around after a distribution change and expecting it to work. Just because something's prefix is /usr/local doesn't mean it won't end up linking itself to a library in /usr/lib. Always beware of the fact that anything you compile yourself might have to be re-built if you upgrade/change your distibution around it as it might be dependant on things that no longer exists.