The Future of Linux From Scratch
The main discussion of late is the direction the LFS project should take. There are numerous improvements to make. This document highlights the following:
- Educational content
- Package management and automation
- Linux Standards Base
- 64-bit LFS
- Licensing and trademark
- Legal (not for profit) organization
1. Educational content
The book needs to improve on the educational front. This “issue” will never get “resolved” as it will always be an ongoing project. We can, however, pay extra attention to a few areas in particular.
There are many areas where after installing a package you don't come away with a true understanding of what you have just done or why a package is needed. Sometimes all you get from it is that another package required it and you'll settle for that.
In other cases there is no real (technical) reason why a package has been selected for inclusion in the book. Take Vim for example. There is no real significant reason for choosing Vim over any other editor other than the fact we had to pick one. Vim was as good choice at the time. Such information should be communicated.
We should also expand significantly on major areas and subsystems. For example, both kernel configuration and udev setup need elaboration. The user is sometimes left hanging after (or in the case of kernel configuration, before) installation of a package. Additional help, information and suggestions would go a long way to steer our users into the right direction.
2. Package management and automation
When people talk about package management it's not always clear what is meant. To simplify, people will typically fall into one or both of the following scenarios:
- Keeping track of files that were installed and modified by a package's installation
- Automating the installation of individual packages or the entire system. This would including re-deploying the installed packages to another system without having to recompile again.
There have been discussions about which package management system to use. We would either 1) have to decide on one, have the book use it or 2) not pick one and devote a chapter to the various choices. In the latter case, the user decides which one (or none) to use.
Choice is good. But it can also be an Achilles heel. If the book is to be made PM-aware we need a sample implementation. Not only for our own internal needs (to speed up editorial and testing cycles) but also to show users how it can be done in showing a fully implemented and working system.
In cases like this it's often best to decide on one to primarily use and assume its use throughout the book. A chapter that talks about Package Management can explain why we chose the one we did and point out that other options exist as well.
We likely won't have the resources to support every kind in the book itself. Keeping one up to date will be enough work as it is on an on-going basis.
If the book is going to officially support a system, it should be one that can provide automated installations and dependency resolving. Not just an installation logger that keeps track of installed and modified files. We'd definitely point out that such a method exists and could be good enough for a group of people, but most people would benefit from something a little more advanced.
Another method of installing software that needs to be considered is to initially install the software in an alternate directory, say /tmp/<packagname> for the user to inspect the files before they are actually installed. This is generally done with a command similar to
make DESTDIR=/tmp/packagename install
The DESTDIR can be a base location for a package manager to gather its data. Note that many, but not all packages honor DESTDIR.
We'll also need to work out how to automate the generation of package management configuration files themselves. Certain files need to be generated to allow automatic building of the packages. The XML code that makes up the book will need some restructuring so build scripts/RPM spec files/etc can automatically be generated rather than keeping a separate set of files in sync with the book.
When using/mentioning the automated tools in the book along with the manual installation commands we'd provide the details surrounding the automation. For instance, rather than just telling people to run “<cmd> install gcc,” explain what happens when you run that, which file(s) make up the inner workings of that command. And most importantly how to modify the file(s) to change the installation process' behaviour.
That would maintain the educational focus of LFS, provide some valuable insights in how a regular distribution's package management system might work and adds value for people who aren't doing LFS for the first time.
3. Linux Standards Base
Linux Standards Base, or LSB, (http://www.linux-foundation.org/en/LSB) is a standard designed to provide interoperability between applications and the Linux operating system. Currently all major distributions comply with the LSB. Testing of compliance is done through a test kit. LSB should be introduced in LFS and instructions for making LFS/BLFS LSB compliant fleshed out in BLFS.
4. 64-bit Support
Multi-lib or Pure or both. That is the question.
5. Licensing and trademark
The current license in the LFS book doesn't do anything to protect us. Bruce has been in touch with an attorney with the Software Freedom Law Center who made some suggestions. It boils down to licensing the book under Creative Commons and an additional note along the lines of “Computer instructions may be extracted from the book under the MIT license.”
This is not the final verdict but some license changes should be discussed and then implemented.
Another suggestion that was made is for us to consider trademarking “Linux From Scratch” and probably “Beyond Linux From Scratch". Since Linus holds the Linux trademark we need to get permission (http://www.linuxmark.org/license.php).
6. Legal (not-for-profit) organization
To continue on the last point regarding licensing, currently the LFS book is copyrighted under Gerard's personal name. The BLFS book under the “BLFS Development Team.” In the past we have had discussions about founding a not-for-profit organization under which the LFS products can be licensed and copyrighted. It would be better than under an individual's name.
We're resuming this research to see what it will entail to setup that sort of organization. There are matters to figure out having to do with finances, receiving money for the LFS project, etc. It's not an easy straight-forward process and also pretty expensive from what we've learned so far.
