I have to use custom versions of Python, Postgresql and Apache httpd. I have uninstalled them and I will compile them from source, it is a local machine and I am the only user.
I am wondering if due to the importance of the applications I should install them in /usr using /usr/lib64 and /var for the library and state folder.

Thanks

Well for the programs that ship with Slackware (that you just want to use a different version of), I would recommend installing them into /usr/local or /opt/<package name> as per the Filesystem Hierarchy Standard. If you install those directly into /usr (where Pat installs them), they may overwrite the files that ship with your Slackware version and cause problems.

I'm not sure about PostgreSQL, but since that doesn't ship with Slackware, that might be okay to install into /usr (don't quote me on this), but I would still install it to /opt/postgresql (personal preference).

1 members found this post helpful.

for Apache /var/www but that is just where red hat puts it

Also look at possibility to turn your custom compilation into Slackware package where you can later manage it with installpkg/removepkg. There is an utility called src2pkg which allows you to turn source tarball into Slackware package.

1 members found this post helpful.

Personally I install libraries in /usr and everything else in /usr/local. This is to avoid the situation where programs will not find the libraries unless they are in /usr.

I instead add /usr/local/lib to my ldconfig.conf or whatever the filename is.

I tend to do what wigry suggests and build a customised package for anything I am replacing.

It is /etc/ld.so.conf, and I have added it, but it still may not find the libs. It depends on the build system as well.

as wigry and GazL have pointed out, best strategy is to use package management, ideally by modifying the original SlackBuild scripts. No harm installing into /usr when under control of package management. When installing manually I heavily recommend using alternative locations just to keep an overview, be it /usr/local, /opt or anything else that taketh your fancy. If the chosen directory represents a separate file system, certain operations down the road become easier (eg. system-reinstall).

No circumstance justifies compiling from source.
The best practice is to use SlackBuilds and create packages, even ones that install in /usr/local or /opt or /home/$USER or whatever.
Even better practice is what SBo does and copy the SlackBuild script used in the documentation directories. That way you can always check how the package you have installed is compiled.

The only exceptions could be binary blobs like nvidia, virtualbox or skype.

Thankfully the good people at slackbuilds.org do provide a slackbuild script to create a slackware package for skype.

A good rule of thumb is one that doesn't come back to haunt you -- I long ago learned that add-on software really should live in /usr/local and add-on applications really should live in /opt. The idea being to keep distribution software; i.e., that provided on installation media, be kept "pristine," un-fooled-around-with.

Why? Well, I partition disk drives so that /opt and /usr/local are mounted file systems (among others) and the system partition only contains that software provided on the installation media -- when an update arrives (such as Slackware 14.0 from Slackware 13.37), it is a simple task to do a clean install (after saving certain configuration files off to a separate partition) by simply choosing to format (or create a file system) on the system partition but not doing so on the "local" partitions thus everything in the local partitions remains in place (this is when you're doing setup and adding disk partitions to fstab). Here, "others" include /var/lib/mysql, /var/lib/pssql and /var/lib/virtual -- they remain in place.

I construct a "standard tree" in /usr/local; bin, etc, include, lib, lib64, man, sbin, share, src. This accomplishes two goals: no system files accidentally get overwritten and the "local" stuff is easy to find. When I'm building packages from SlackBuilds.org I modify the packagename.SlackBuild file (if necessary) to install in /usr/local, similarly, if I'm building something from source (with configure-make-make install) using src2pkg, I force src2pkg to install in /usr/local.

It's no trick to add to /etc/ld.so.conf:
Slackware already includes /usr/local/bin on the system PATH environment and it's easy enough to make simple changes to a user .profile file for other needs.

Keeping "church and state" separate is just a good idea that will save trouble down the road, methinks.

Hope this helps some.

1 members found this post helpful.

I'd say that that's never a best practice.

Just build custom Slackware packages and use upgradepkg to swap to them. SlackBuilds for Python and Apache in /source. Change the names of the packages from "*-1.txz" to *-1[YOUR_INITIALS].txz" so that they're recognized as custom builds. SlackBuilds for Postgres and for Python 3 are on SBo.

1 members found this post helpful.

I compile from source all the time and I don't see what justification I would need ... because I feel like it.

I'm pretty sure Sahko meant that no circumstance justifies doing a "make install" into /usr (or /usr/local or /opt).