As much as I enjoy compiling my own operating system, I am already beginning to wonder how I might get more involved in the process of actually determining what the commands and dependencies are for installing packages.

How does one decide which packages are to be used in LFS and how they are compiled? Is there some way that LFS users might make some investigations into this area themselves?

Well, I would presume the base packages are usually needed to make your OS a working interactive OS. You can skip some of the packages, but some require those packages to function properly. Like if you just wanted to use the kernel, what good would it do you if had it running but couldn't do anything else? Everything works together so the OS will work as one.
What your asking is the same as can I build a car with no wheels? Sure but your not going to get very far are you?

I see what you are saying, but I'm not just wondering about which packages to use, I'm also wondering about which versions and how you decide which compile or configure options to apply.

LFS assumes a certain amount of ability in using the command line interface. But a certain amount of familiarity with the actual commands like "configure" and "make" are also assumed. I am fortunate to have successfully compile software that I wanted to install on my system without actually having any programming experience. I have an idea what is going on when I am instructed to perform these commands. I am convinced that it is possible and even desirable to introduce the beginner to this functionality.

And so I wonder, how is it decide which versions of packages are applied and which options are used?

See also my post about my problems with XFree86.

I can't say with any certainty, but my guess would be that the LFS folks depend on the documentation provided with the packages themselves for what options to use. Almost all packages include a README, INSTALL, and other goodies to read that SHOULD describe what arguments to configure and make are needed for a given setup. Some of them are pretty standard (like '-prefix=<dir>' for configure). You can read over the options yourself, and if you see something that would suit you better than the LFS suggestion, go for it. Just realize that depending on what your choice changes, it could have an impact on other packages later on (if, say, package B depends on package A to behave a certain way). If you make a change to one package, you'll just have to read over every package's list of options and change their options IF that original change has an impact. Or you could just keep your fingers crossed (my personal favorite).

The rest is just deciding an organizational scheme for where to put the executables and configurations, and knowing what the dependency requirements are for each package. Again, that SHOULD be mentioned somewhere in one of the supplied documents in the source archive. Otherwise, the developers are relying on the configure script to inform you of any missing prerequisites.

And as for which version of each package to use. I imagine it's fairly arbitrary. They probably don't grab the latest and greatest because it's likely to have problems. Versions that haven't had much patch activity in a while are good candidates because they've become stable. The rest would just be trying out a combination of packages to see if they play well together.

That sounds encouraging. It sounds like really going beyond LFS would be going to places like Freshmeat or SourceForge entirely on your own initiative. I am already finding my way to the READMEs that come with NFS packages to see how to get my NFS client going. The hints at the LFS hint site aren't covering my problems.

You've got the idea exactly. You use LFS and BLFS to build up your basic system, and then grab whatever software makes you happy from that point on.

One thing I would suggest doing before grabbing other application software: Backup your system at one or both of these points:

1) You finished the LFS portion and have an operational system
2) You finished installing extras from BLFS

That way, you can always step-back if something goes wrong with the other software you install. It takes a while to build an LFS system. It's a real heart-breaker realizing you have to start from scratch again (no pun intended) because you accidentally screwed something up trying to get that new, neato-keen piece of software working.

I've had a few occasions to look into CVS and somebody else mentioned it here. Would that have any applications for somebody with LFS/BLFS installation?

In my opinion, system backups and CVS are compliments to one another. It's not effective to employ only one. Although a lot of people will perform backups, but overlook CVS. Here's how they're different.

I'm sure you're familiar with a system backup. It provides a snapshot of every file on your machine at a given time. If something goes wrong, you CAN wipe the system clean and install from the backups. The point I'm making is that backups tend to be used to work on all the files on a system as a whole.

CVS provides a revision system. It operates on individual files. Using its check in and check out routines, you keep a history of the changes to that file and can step back for that file specifically without affecting other files on the system. This is ideal for configuration files (/etc/profile, /etc/XF86Config, bootscripts, etc. ). If you tweak a configuration and it doesn't work, then you can roll back to the previous working configuration without reinstalling the system.

Using CVS as a backup scheme for the whole system isn't a good idea though. You have to manually update every file that changes with the check in and commit commands. So, when installing new software, you can see it would be extremely tedious to find every file the install copied over to your drive in order to check it in.

If you choose to use either/both, you need to be persistent with it. If you update a lot of your system without a backup, then if something goes wrong, you'll have a lot of work to do getting from your backup back to where you were. If you make a lot of changes to a configuration file, but don't check it in, then the same thing happens here; you might have to re-read an extensive man page to remember how you managed to do something earlier.

I don't know if any of this made sense or not. I'd be willing to give it another shot later though. Right now, I'm a little groggy having rolled out of bed not too long ago... So, the above message might need a decoder ring...

Got it.