| 16 | | I. Introduction |
| 17 | | |
| 18 | | There have been many LiveCDs (aka BootCDs) made and used within the LFS |
| 19 | | community. Of particular note were Chris Lingard's and Jeremy Utley's. By some |
| 20 | | random freak of chance, and perhaps a bit of persistence on my part, a CD of |
| 21 | | mine was chosen to be used as the 'Official' LFS CD with the release of |
| 22 | | LFS 6.0. |
| 23 | | |
| 24 | | I based much of my work on the ideas and work of Chris and Jeremy, and from |
| 25 | | suggestions and comments from various LFS users, but the originalCD had still |
| 26 | | been largely my work. However, for the idea of an official CD to survive and |
| 27 | | grow within the community, help and ideas need to continue to come from more |
| 28 | | than just one source. |
| 29 | | |
| 30 | | My intention with the LFS LiveCD project, then, was to devise a framework, a |
| 31 | | usable setting in which others may contribute and build CDs that live up to the |
| 32 | | official standard. Originally, the idea was just to keep config files and a |
| 33 | | list of required packages in a Subversion repository. What actually happened |
| 34 | | was that a fully automated scripting system was devised specifically for the |
| 35 | | purpose of building the LiveCD iso. This allows both an easily repeatable way |
| 36 | | of building the CD and a means to track its configuration and history. |
| 37 | | |
| 38 | | Many thanks to all who have contributed to the production of these Makefiles |
| 39 | | (and the CDs they in turn produce) by either suggestions, ideas, support, or |
| 40 | | submitted edits. |
| 41 | | |
| 42 | | - Jeremy Huntwork |
| 70 | | is called and run. These download the source files it needs, verifies that |
| 71 | | they are correct via sha1sum, unpacks the tarballs into its own directory, |
| 72 | | runs the build instructions and sends the output into a log-file. |
| | 41 | is called and run. These download the source files needed, verify the SHA1 sums, |
| | 42 | unpack the tarball(s) into its own directory, run the build instructions, and |
| | 43 | send the output into a log-file. |
| 98 | | This signifies the root-point of the build scripts. In other words, this |
| 99 | | is the name of the actual directory containing the build scripts. Default is |
| 100 | | /lfs-livecd. If you accept the defaults for both this variable and MP, then |
| 101 | | this directory and all its sub-directories should exist as 'lfs-livecd' within |
| 102 | | the direcotry '/mnt/lfs'. It is important that this variable have a leading |
| 103 | | '/' as it is referenced by the scripts in both the host environment and the |
| 104 | | chroot environment. |
| | 66 | This signifies the root-point of the build scripts. In other words, this is |
| | 67 | the name of the directory containing the build scripts. A symlink will be made |
| | 68 | from this directory to the root of the host filesystem. The default name of this |
| | 69 | directory is lfs-livecd. If you accept the defaults for both this variable and |
| | 70 | $MPBASE, then this directory will exist as /mnt/lfs/lfs-livecd. A symlink will |
| | 71 | be made to /lfs-livecd on the host system. It is important that this variable |
| | 72 | have a leading '/' as it is referenced by the scripts in both the host |
| | 73 | environment and the chroot environment. |
| 106 | | * PM |
| 107 | | This is the level of parallel building you want make to use for each |
| 108 | | package. Default is -j3, but you may wish to increase or decrease it slightly |
| 109 | | as the case may be. |
| 110 | | |
| 111 | | Any of the other variables could be changed, but that isn't recommended. Some |
| 112 | | of them are crucial to the successful building of the CD, especially the ones |
| 113 | | containing environment variables. |
| | 75 | All of the above variables (and others) can be edited directly in the |
| | 76 | top-level Makefile (the one in the same directory as this README). However, if |
| | 77 | you are tracking SVN, then each 'svn up' will overwrite your custom changes. To |
| | 78 | overcome that, you can create a file called 'Makefile.personal' and add the |
| | 79 | desired changes there. The original Makefile will source that file. 'svn up' |
| | 80 | will not affect 'Makefile.personal'. |
| 117 | | The scripts will attempt to download the sources as it needs them. Since it |
| 118 | | is highly unlikely that you will have all the correct sources already |
| 119 | | downloaded to your system, a working internet connection is almost a |
| 120 | | necessity when using these scripts. |
| 121 | | |
| 122 | | If you want to gather the source packages you'll need beforehand, you will |
| 123 | | need to create a directory called 'sources' in the $(MP) directory and place |
| 124 | | your packages there. You should either ensure that you download the *exact* |
| 125 | | same package from the same URL the scripts use, or you should verify that |
| 126 | | the SHA1 sum in that package's Makefile matches the tarball you have |
| 127 | | downloaded. |
| | 84 | The scripts will attempt to download the sources and book patches as it needs |
| | 85 | them. If you want to gather the sources and book patches beforehand, create a |
| | 86 | directory called 'sources' in the $(MPBASE) directory and place the sources and |
| | 87 | book patches there. You should ensure that you download the *exact* same sources |
| | 88 | and book patches the scripts use and then verify the SHA1 sums. This will |
| | 89 | prevent the build from failing unexpectedly on a bad checksum during the build. |
