SlackwareThis Forum is for the discussion of Slackware Linux.
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.
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".
This directory is reserved for all the software and add-on packages that are not part of the default installation. For example, StarOffice, Kylix, Netscape Communicator and WordPerfect packages are normally found here.
The original idea behind '/usr/local' was to have a separate ('local') '/usr' directory on every machine besides '/usr', which might be just mounted read-only from somewhere else. It copies the structure of '/usr'. These days, '/usr/local' is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.
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.
Last edited by harryhaller; 09-18-2008 at 07:42 AM.
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.