-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME.CUSTOM
262 lines (192 loc) · 9.34 KB
/
README.CUSTOM
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
HOW TO ADD CUSTOM SCRIPTS TO THE JHALFS MAKEFILE
Normally JHALFS creates a Makefile containing only those scripts found in
the {,B}LFS books. An automated construction tool cannot predict the
needs of every individual and requests are made "Can you add xxxx package".
Rather than adding numerous package scripts and switches for each request it
was easier to add a tool for the user(s) to code their own package needs.
There are two areas that can be customized: how the base system is built
and what additional configurations and packages your hardware requires to be
able to boot and run. Each of those areas are handled in a different way.
BASE SYSTEM CUSTOMIZATION
There are two ways to alter how the base system will be built:
- Using a working copy of the book sources and editing the XML files.
This is the way used by book editors to test packages upgrades,
command changes, build order changes. etc.
This method requires you know very well the book sources and what
files need be edited. It will not be discussed here.
- Editing the generated build scripts to make any change you want.
This is the method discussed below.
EDITING THE BASE SCRIPTS
To begin with, the build scripts should be generated with book defaults. To
do that, configure jhalfs activating any option you want included, but do not
select "Run the Makefile" option.
Under the ${BUILD_DIR}/${SCRIPT_ROOT}/$COMMANDS directory
(using the defaults values to do an LFS build, that directory name is
/mnt/build_dir/jhalfs/lfs-commands) you will find the default build scripts.
If all you want is modify, add, or remove some command from a package
installation, for example to change its ./configure line, just edit the related
script. If changing or adding a patch, be sure to copy the new patch to the
${BUILD_DIR}/sources directory. When done, run 'make' from inside the
${BUILD_DIR}/${SCRIPT_ROOT} directory.
REPLACING OR INSERTING PACKAGES AND CHANGING BUILD ORDER
To remove a package from the system, just remove its script(s).
To change the version of some package, or to build a newer or older version
than that in the book, edit ${BUILD_DIR}/${SCRIPT_ROOT}/pkg_tarball_list to
change its tarball name and place the new tarball in the ${BUILD_DIR}/sources
directory.
To replace a package by an equivalent one, rename the replaced package script
to reflect the new package name (for example, 102-man-db -> 102-man), edit the
script to make the required commands changes, place the new tarball in the
${BUILD_DIR}/sources directory, and edit ${BUILD_DIR}/${SCRIPT_ROOT}/pkg_tarball_list
file to replace the removed package tarball name by the new package tarball
name.
To change the build order, rename the scripts changing the first 3-digits
string until they are sorted in the way you want.
To insert a new package, for example to build Cracklib in order to build
Shadow with Cracklib support, you should first decide before what package it
needs to be installed, in this example 107-shadow. Then create a new script
containing the needed commands, using an existing one as template, and name it
with the same 3-digits string used for that mentioned default package, but
adding another 1-digit string. In our example, the new script to build Cracklib
before Shadow will be named 107-1-cracklib. This naming scheme allows inserting
up to 10 scripts before each of the existing scripts. Place the tarball for
the new package and required patches, if any, in ${BUILD_DIR}/sources and edit
${BUILD_DIR}/${SCRIPT_ROOT}/pkg_tarball_list to add the tarball name for that
package.
When ready, launch again the jhalfs configuration interface. Make sure that
exactly the same options are selected as when generating the default build
scripts. Be sure that "Rebuild files" is unselected and select "Run the
Makefile" if you want. Then select "Rebuild the Makefile". This will create a
new Makefile based on the changes you made to the build scripts.
ADDING POST-SYSTEM BUILD CONFIGURATION FILES AND EXTRA PACKAGES
The installation of BLFS packages is handled via blfs-tool and activated
when you select the appropriate menu option. See README and README.BLFS for
more info.
The feature described below was added so users could install remaining
configuration files, build the packages necessary to access the Internet
or to support specific hardware, or to install basic utilities that are
needed from the beginning, and was not intended to replace the BLFS
install system.
LAYOUT
A new directory has been added to JHALFS tree which contains the
configuration scripts and a few examples. A switch has been added to the
configuration file which enables/disables the inclusion of custom scripts.
custom
/config <-- where to put your scripts.
/examples <-- a few example scripts
template <-- ALL scripts MUST look like this
NOTE::: You are responsible for including all dependencies and ensuring they
are built in the right order.
1. To add a package to the final JHALFS Makefile you must first create a file
in the custom/config directory. The directory custom/config may need
to be created first.
**All config files MUST follow the naming convention, xxx-PKG, where xxx
is the order number and PKG is the name of the package. The file naming
format is important as it defines the build order. The example shown
below has an order number 950 and log files will list in alphabetical
order in the /logs directory after blfs-tools scripts.
The simplest method is to copy the template file into the config directory
and rename it.
2. Populate the variables with the necessary values.
Variable function is self explanatory. PATCH variables must be
numbered, starting at PATCH1 (up to PATCH10). If the md5 checksum value
is known, it can be added after the URL as in (quotes needed):
PATCH1="http://patch-host/patch-path xxxxxxx..."
3. Build commands
If the package you want to include is found in the BLFS
book then you only need to copy/paste the commands between the xEOFx
text, otherwise you will need to define the commands yourself.
NOTE::: This script you just created is not usable directly but contains
all the information necessary for jhalfs to create a build script
and an entry in the jhalfs Makefile.
4. As mentioned previously the build order is dictated by the 3 digit number
in the file name. If a package has dependencies it must be numerically
larger than the dependency files.
e.g. The package mc has glib as a dependency, so the build order is:
950-glib
951-mc
5. A config file for BLFS-bootscripts is already created as 999-blfs_bootscripts.
If a package requires a bootscript to be installed add the cmd to this
file and NOT in the package script. The gpm script is included as an
example of patch file and the need for a blfs bootscript.
EXAMPLES
Other examples can be found in custom/examples. They are dated and
unmaintained, but can be useful for creating your own scripts.
#--------- GLIB example -----------
#
# Filename syntax xxx-PKG ie. 950-glibc
# Create a file in the custom/config directory
# Populate the file using the following script as an example
#
PKG="glib"
PKG_VERSION="1.2.10"
PKG_FILE="glib-1.2.10.tar.gz"
URL="http://gd.tuwien.ac.at/graphics/gimp/gtk/v1.2/${PKG_FILE}"
MD5="6fe30dad87c77b91b632def29dd69ef9"
# The following code removes previously defined PATCHx variables
for i in PATCH{1..10}; do
unset $i
done
# Patches are named PATCH[1..10]
# This information is used to download the patch only
PATCH1="http://www.linuxfromscratch.org/patches/blfs/svn/glib-1.2.10-gcc34-1.patch 0077a1cce5e8a2231ac5a9b08c6263ba"
# NOTE::
# The convoluted scheme used to write out a temporary file is
# a work-around for embedded single and double quotes.
( cat << "xEOFx"
patch -Np1 -i ../glib-1.2.10-gcc34-1.patch &&
./configure --prefix=/usr &&
make
make install &&
chmod -v 755 /usr/lib/libgmodule-1.2.so.0.0.10
xEOFx
) > tmp
#--------- GPM example -----------
PKG="gpm"
PKG_VERSION="1.20.1"
PKG_FILE="gpm-1.20.1.tar.bz2"
URL="ftp://arcana.linux.it/pub/gpm/gpm-1.20.1.tar.bz2"
MD5="2c63e827d755527950d9d13fe3d87692"
for i in PATCH{1..10}; do
unset $i
done
PATCH1=" http://www.linuxfromscratch.org/patches/blfs/svn/gpm-1.20.1-segfault-1.patch"
PATCH2=" http://www.linuxfromscratch.org/patches/blfs/svn/gpm-1.20.1-silent-1.patch"
( cat << "xEOFx"
patch -Np1 -i ../gpm-1.20.1-segfault-1.patch &&
patch -Np1 -i ../gpm-1.20.1-silent-1.patch &&
./configure --prefix=/usr --sysconfdir=/etc &&
LDFLAGS="-lm" make
make install &&
cp -v conf/gpm-root.conf /etc &&
ldconfig
# The normal cmd to install the boot script for gpm
# --- PUT THIS CMD INSIDE 999-blfs_bootscripts
#make install-gpm
cat > /etc/sysconfig/mouse << "EOF"
# Begin /etc/sysconfig/mouse
MDEVICE="/dev/psaux"
PROTOCOL="imps2"
GPMOPTS=""
# End /etc/sysconfig/mouse
EOF
xEOFx
) > tmp
#--------- CMDS ONLY example -----------
# This is an example of a self contained cmd script
# There are no referenced to a package or package dir.
# This method is useful for creating user files/profiles/etc
# at build time.
PKG=""
PKG_VERSION=""
PKG_FILE=""
URL=""
MD5=""
for i in PATCH{1..10}; do
unset $i
done
PATCH1=""
( cat << "xEOFx"
echo "JUST A USELESS TRACE"
xEOFx
) > tmp