So over the last few chapters I've been promising you a lot that I'd talk about Community Based Linux From Scratch, not to be confused with another project called Beyond Linux From Scratch, another project which was fodder for a terrible Dr Who joke earlier in the git section.

Originally, back when the Linux from Scratch project was new, the bare bones system that was produced wasn't very useful to most people. An effort to provide instructions for commonly used open source software for Linux was made, and the Beyond Linux from Scratch project was born. CBLFS aims to be to CLFS what BLFS is to LFS. However, CBLFS accomplishes this task with a wiki that is open to the general public. I've made some edits myself; a fun easter egg might be to find them some time. Thanks to the wiki interface, CBLFS provides even faster the resource that LFS and BLFS provided to the open source community in general: a quick and easy way to look up information that "just works" for almost any open source software package out there, no matter what OS you use.

Beyond that, they can explain who they are much better in their own words,

http://cblfs.cross-lfs.org/index.php/Main_Page#What_is_Community_Driven_BLFS

And for this task, you'll want to go to that page anyway. A little below the section I linked to, there are post installation configuration instructions, much like those in the beginning of the BLFS book. At a minimum, you'll want to read through the "Bash Startup Files" and "System Users and Groups" pages.

Sections

A typical CBLFS page will have the following sections:

• Download Source: A direct link to the source tarball, along with any manpages and patches that are required
• Table of Contents
• Introduction: Flavor text (I like copying and pasting this directly into the descriptions in my spec files, if you hadn't noticed), usually with a link to the developer's website
• Dependencies: One thing I wanted to cover, and this is as good a place as any: How do you resolve circular dependencies?
  • 
    What I mean by that, is that let's say A depends on B, and B depends on C, and C depends on A. Usually this only comes up with optional dependencies, but not always
  • The solution is a technique called "bootstrapping". It's a reference to the idiom "pull yourself up by your bootstraps", which aside from being a really ineffective way to jump up in the air if taken literally, is an analogy for being self-sufficient.
  • Bootstrapping involves building a bare-bones version of A. In rare cases, if only part of A will build but not the rest of it, you can build that part with the command:
    
    ~ make -C partyoudliketobuild
    
    and then you can build package B with some environment variables set like so:
    
    ~ CFLAGS=-I../A-1.2.3/partyoudliketobuild \
      LDFLAGS=-L../A-1.2.3/partyoudliketobuild \
      ./configure --config-options
    
    where 1.2.3 would be the version number for package A, and config-options would be the options you'd pass to package B's configure script.
    
    Usually you won't have to do that. If package A will install at all, even if it won't install with all the features you'd like to build in, just install package A.
  • Once you have package A, you then build package B, then C, and then A again, with all the features you'd like.
  • In even more extreme circumstances, you can patch files. This gets a little in depth, but you can check out the troubleshooting section for more information. Generally, you'll want to edit libraries out of Makefiles and headers out of c and cc files.
• Build instructions: These usually come in non-multilib and multilib sections. If you're like me, you'll only need the non-multilib instructions.
• Contents: Something else I'm fond of copying and pasting into my spec files

When CBLFS Is Not Enough

Sometimes, you'll come across a package you'd like to build, there are no CBLFS instructions available, and you simply don't have the time or drive to roll your own. When you are in this situation, you'll want to look into a wiki for a source based distribution. Gentoo and SourceMage, like your own CLFS system, use source based package management. The SourceMage wiki is located here:

http://wiki.sourcemage.org/

And the Gentoo wiki here,

http://wiki.gentoo.org/wiki/Main_Page

But probably most immediately useful to you is :

http://slackbuilds.org

The reason why they come so highly recommended, is because they make the fewest assumptions about your system and build utilities that I've been able to find online. You can sometimes remove the installpkg command (and several document packaging commands) from the end of a SlackBuild script and run it to install a package on a non-SlackWare system.

Another option to you, since you know how to read spec files, is to look for a source rpm (srpm) file online. The downside to this approach is that RedHat does make some assumptions about your system; the upside is that you will only ever have to slightly modify an srpm spec to get it working on your system with your native package management system.

You can also install a binary package management solution from another distribution. There's nothing stopping you from installing apt-get, installing some core packages, and suddenly being able to use debian packages. You're limited only by your imagination and willingness to research.

Congratulations, and thanks for reading this. Please leave me any feedback in the comments section below. Good luck and enjoy your OS!