If you put something in the core system and it doesn't function, then you are facing greater problems than if you had put it into /usr/local.

/usr/local, as a separate partition, can be simply dismounted.

As for compiling - well I have /usr/local prioritised both in my paths as well as in ld.conf.

Hence if you have the old standard program in the core sytem and the new program in /usr/local, when you run the program the newer version will run. Problems? Unmount /usr/local, try again and if it works, you know where the problem is - and, more importantly, you can carry on working.

The other aspect is creep - at what point do you have a slackware distribution and at what point do you have a system based in Slackware?

Ad absurdum - one would end up having an lfs system since you have given up the idea of keeping the core system strictly separate from any changes/additions you make.

If yours were a business - a bank say - an IT auditor would have grave considerations about tampering with the core system. S/he would want all changes/additions to be kept separately so that they could be given special consideration.

Surely the same would apply to us when debugging a problem? We could focus on where changes had been made much easier if they were kept separately.

Anyway that's my attitude.

If I were to continue putting changes/addtions into the core system, I would really consider moving onto LFS - after all, I would be be half way there.

Slackware would then be a useful source of packages for when I was to lazy to compile myself and a reference system.

I wouldn't have /usr/local because the whole system was "local".

And /opt directory has not been discussed yet

/opt seems to be just for packages - as opposed to individual programs.


So I stand corrected about what I wrote about keeping the original program in /usr, but otherwise my point of view agrees with the standards that additions should be placed in /usr/local.

YOu have to take into account common practices -which means that most users/admins will install any *packaged* software with, usuallly, a prefix of /usr. /usr/local is most often used for software that is installed without packaging it and for a place to put single-file installations -that is short scripts which don't have any ancillary files.
/opt was originally designed to be used for any software which doesn't conform to normal pratices of spreading files out in different places. that is, some programs look for all their files under a single directory. /opt provides a place for htese programs -anything in /opt can follow whatever conevntion they want. usually progs there are installed into a single directory.

The one rule about /usr/local that most distros do folow is that it should be emptied as the distro is delivered.
In summary, if you want to do like everyone else is doing, only put stuff in /usr/local which is installed manually or by using 'make install, or an install.sh script. If you create packages for installation , they should nearly lawys be in prefix /usr, although there are exceptions. Some exceptions are really 'illegal', -products which create their own subdirectory in /usr. These should usually be installed, instead in a subdirectory under /usr/lib (no capitals in the name). Then links or wrappers to the binaries are placed in the normal path /usr/bin.

While true that pkgtool will manage packages installed under /usr/local and that some third-party packages may thus overwrite files from the official packages, this is still the most common practice across almost all distros. The biggest 'violators' have historically been several large open-source cross-platform programs, like X11, KDE, Mozilla and others.

If you create a package using prefix /usr/local, installing it with installpkg will still keep the database info under /var/log/packages. If you had a separate partition mounted on /usr/local you could use root=/usr/local installpkg pkgname to install the program there, but that is not correct -pkgtool rightly will ignore the database files which get installed to /usr/local/var/log/packages.
The 'root' option to installpkg is used when you are creating a complete installation under a certain subdirectory, which will be mounted as the main / partition afterwards(or if you want to copy the whole thing to some device).

As soon as you finish installing Slackware, it becomes yours -very few installations are left exactly like the installer created. It doesn't mean you should just go ahead and use LFS, just because you change the hostname or add a package or two(hundred) which are not part of the official release. Slackware users rarely rely 100% on official packages.

If you find anyone else distributing binary packages for Slackware which are installed under /usr/local, you should consider that a bug -no reputable packages is going to do that, and if someone does that, it screams that they don't know what they are doing -even though it may be 'legal', it is just simply not the accepted practice.