Many of the sections in the LFS book require some housekeeping steps after installation of a particular component. Some of these are repetitive. For example, 6.25 through 6.27 each require us to manually move a lib to a target dir and then create a symlink. 6.22 and 6.24 each require several specific housecleaning steps to move/link compiled artifacts and those steps are specific to those sections.

Why don't the package authors include these housecleaning steps in their make install targets?

Since I'm not a longtime Linux user or GCC expert, is it normal to have to do these housecleaning activities when not using a package manager in a non-LFS Linux environment? If we download source code and compile in a "normal" non-LFS distro would we be expected to either magically know the steps required to get each package installed or figure them out from reading the docs / source code?

Or are these issues rather specific to LFS and not something we would encounter normally?

Package formats in binary distros like Slackware or Debian typically include a shell script to carry out jobs like moving the odd library or making extra links. Therefore the user does not notice them. In LFS, there is no provision for such scripts so you have to do it yourself.

Moving libraries around is the commonest LFS operation because makefiles have a single destination (usually /usr/lib if the configure prefix was /usr) for all their installed libraries, but sometimes one or two of these are important enough to need to be moved to /lib instead, leaving a symlink in /usr/lib just in case. Remember that if programs in /bin or /sbin need a particular library, it has to be in /lib.

Thanks again hazel. So my question really is, if a file is important enough to be in /lib, why doesn't the install target for the Makefile of that package as written by the package author actually move the file to /lib by default?

I'm assuming this comes down to many of these software packages being more universal than even just different flavors of Linux i.e. they need to work across multiple *nix architectures potentially going back decades with potentially very different filesystem layouts -- is that a correct assumption? But even then I would think the author could add a check to try to determine what type of Unix/Linux it is installing on and take appropriate default steps, or maybe use a ./configure switch or check an env var that could be passed specifying where those files should be moved. That way the installer does it automatically. We are already passing command line options to configure and make throughout LFS so clearly they already do that to some extent.

Or is there some other reason I'm not thinking of?

The "make install" scripts have nothing to do with "LFS" and upstream defaults these days favour the "usr merge" scheme that most distributions have been coerced into adopting. Most distributions these days dump EVERYTHING in /usr, and /bin, /sbin, /lib etc. are symbolic links to catch non compliant installs. Some distros have even gotten rid of libexec. Want to mount /usr off onto a separate partition? Too bad for you, they'll say that's "no longer supported".

To some extent the targets are configurable, for example with autoconf based builds you can set --prefix=/usr and then --bindir, --sbindir and --libdir and stuff separately. The problem comes, for example, when you don't want ALL the binaries in /bin, hence manual moving.

Yep I get that the installation scripts aren't related to LFS.

What I'm wondering though is WHY the LFS text contains some of these commands. In some cases it is explained but in others it's not. What is the reasoning behind selecting the commands we are told to run after an install is complete?

For example, 6.29 (Psmisc) includes a couple of mv commands at the end and the text states they are moved to comply with FHS. Ok got that, the reason for these commands is explained clearly.

But then 6.25 - 6.27 each include a mv and link with this explanation:

Ok so I can see why there could be a need to create the link because of the move, but why move the file in the first place? It isn't explained, we are just told "move this file."

6.22 (Bzip2) has a similar one, where we run make install but then it has a series of steps requiring us to:

What is the "WHY" behind the LFS text selecting those specific commands to run after the install is complete? WHY is the binary moved to /bin? WHY are the symlinks "necessary"? Etc.

I'll confess my issue may be lack of experience with Linux, this is my effort to learn more about it at a deeper level so I may be missing something fundamental here. I'm doing a lot of ancillary reading including looking up items in The Linux Programmer Interface text and multiple sources online too as I go. So I'm trying to gain a better understanding of why the LFS text chooses to run certain post-install commands that often aren't explained.

Thanks.

I explained this above. Essential libraries have to be in /lib, not in /usr/lib. Essential commands have to be in /bin or /sbin. This includes gzip and bzip2. gunzip and bunzip2 are symbolic links to these and are also required to be in /bin. Less essential variants of these programs such as zgrep and bzgrep can stay in /usr/lib where they were originally installed.

In the past, /usr was often a separate partition. Sometimes there was only one copy of it mounted on the office server and other machines mounted it remotely. If the network went down or if something went wrong with that drive, you needed to have all the essential tools on your root partition.

Ok got it. For some reason that wasn't clicking with me until now. I've read a bit about essential (for boot) vs non-essential programs & libs so I get the gist here.

So this sparks another related question (and hopefully I'm not too annoying!) -- how do we know if a particular program or library is "essential" to system function? I mean beyond "because it's in /bin or /sbin or /lib" which is circular -- since we are building LFS then there is prior knowledge required to determine which programs/libs are essential vs non-essential, but how did the LFS authors decide which programs are "essential" vs not?

Is there a master list somewhere of which programs and libs are "essential" to Linux? Or is it just a matter of trial and error experience over time?

That's what the official file system hierarchy is for!

Gah! I had looked at the FHS layout but never realized it actually defined the bins & libs needed.

This answers so many questions!

THANK YOU!!!

Ok so there's another question spawning from this...

The FHS standard entry for /lib doesn't really specify which files must be in /lib other than the C library and linker.

LFS 6.25 (Attr) has this post-install instruction: (also 6.26-6.27 and several others throughout the book IIRC)

How do the LFS authors make this decision? If it is essential to boot why isn't it defined in the FHS? How do we go about determining if a particular library belongs in /lib other than "because the book says so"?

BTW this has been hugely helpful in boosting my understanding of what the LFS book is doing so I greatly appreciate the responses so far.

It has to be in /lib if programs in /bin or /sbin use it.

And that one sentence closes my knowledge gap. For some reason I was reading the statement in the FHS docs incorrectly and now rereading it its blatantly obvious.

Thank you again hazel you have been extremely helpful as always!