Extending beyond the basic system

I am using the automated build system to continue installing software as time goes by. This is by re-using the jhalfs directory and a Makefile patterned after one that was used in the basic system build. I don't know if it qualifies as a sort of package management system or not. It records what packages are installed and it keeps logs that can be examined for information about files and file locations that were installed with each package. By re-doing the same configure command, and then 'make uninstall' a package can be 'mostly' uninstalled. Any number of packages can be built using commands that are partly based on the BLFS book and partly based on the template in /jhalfs/custom.

The latest method involves two scripts make_custom.sh, remake_custom.sh, and a Makefile called Makefile.custom which is derived from many experiments with building custom tools with jhalfs.

This method will only work after booting into the lfs system. The password for the root account must be set up. There are a few prerequisites that must be installed first. The bash startup files should be set up, sudo should be installed, the user jhalfs should be added with 'useradd -m -u 101 jhalfs', and jhalfs should be added to sudoers with visudo. I gave jhalfs the uid 101 since the live cd gave it that and I didn't want conflicting file ownerships in the /jhalfs directory. I'm sure more learning about Makefiles and the jhalfs system could lead to more flexible arrangements.

The script make_custom.sh does nothing more than run make using the special file Makefile.custom by executing the command "make -f Makefile.custom".

The script remake_custom.sh does several things but most importantly, it converts the scripts in /jhalfs/custom/config to scripts in /jhalfs/lfs-commands/custom-tools and then rebuilds the file Makefile.custom so that the scripts that have not run to completion will be run. Once a script runs to competion, a file by the same name as the script is created via 'touch' in the /jhalfs directory to satisfy that target. Removing one such name from the /jhalfs directory would inspire make to make that target and all subsequent ones. A brief explanation of what remake_custom.sh does is that it uses the top portion of Makefile.custom up to the line beginning with CUSTOM_TOOLS: and then appends code to run all the scripts in /jhalfs/custom/config, and then it (optionally non-interactively) downloads any needed PKG_FILE (s) that are not already in /sources.

When each script is run, a log with the same name is started in /jhalfs/logs and progress may be monitored with tail -f /jhalfs/logs/script_name. If configure, compile, or install errors occur, the log may be examined for clues. If at a later time there is a question about how a package was configured, the logs provide a reference.

Creation of the scripts in /jhalfs/custom/config is mentioned in README.CUSTOM and there are examples in /jhalfs/custom/examples. More examples of these scripts can be seen in first fully automated build and gnome from scratch. I have created a slight variation of the file /jhalfs/custom/template that I called template-url which makes it a little easier to compose the url for a package. Linux From Scratch maintains a location where a majority of the packages can be downloaded from and most (but not all) are available in .tar.bz2 format. Some that are not in that format might be available in .tar.gz, .tgz, or .zip formats. Due to the design of the jhalfs system, it is very important that the variable PKG_FILE resolves to the exact tarball name if it needs to be unpacked. There are some cases where the tarball name is so non-standard that the variable PKG_FILE must be set to the tarball name because it cannot be composed from the parts of the name, i.e., ${PKG}-${PKG_VERSION}. If the script does not involve unpacking a tarball, then the variables PKG, PKG_VERSION, and PKG_FILE should be blank. Any of 10 variables PATCH1, PATCH2, ... PATCH10 can be set to a url which can be downloaded by remake_custom.sh, but any code to apply patches must be coded into the script in /jhalfs/custom/config.

If the scripts in /jhalfs/custom/config are created correctly, then remake_custom.sh will set up the build scripts and the Makefile.custom and will even download the missing source files to the /sources directory.

The scripts in /jhalfs/custom/config should be named in such a way that the ls command would show a listing of the scripts in the order that they should be built. Prefixing script names with a number such as 1000-gpm is a handy way to ensure the desired order.

Usage:
Create or modify scripts in /jhalfs/custom/config
sh remake_custom.sh
sh make_custom.sh

If you only want it to build up through a particular target such as 1000-gpm, you can run it like:
sh make_custom.sh BREAKPOINT=1000-gpm
and the jhalfs system will stop the building when that step is done.

Unless it is desired, there is no need to delete preexisting scripts from /jhalfs/custom/config. When reorganizing the build order of scripts, deleting old or unused names may be a good idea. For example, if I copied 1000-gpm to 1380-gpm, I would most likely want to delete the 1000-gpm to avoid building both. Removing historical versions of scripts from /jhalfs/lfs-commands/custom-tools would be a matter of choice.