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
|
slacktrack version 2.00
Release notes: 17th September 2008
===================================
Highlights:
-----------
slacktrack no longer uses 'installwatch' to track the installation
process -- what was previously called 'altertrack' has been turned
into 'slacktrack'.
slacktrack's method of tracking package installations is to
have the package installed directly onto the host's filesystem.
This is for a number of reasons:
1. installwatch is ill maintained and was failing to work correctly
with new versions of glibc and GNU 'coreutils'.
2. installwatch could not track statically compiled binaries,
meaning that if a statically compiled binary was used to
manipulate the filesystem in any way, these manipulations would
not be reflected in your package contents.
3. With virtualisation -- QEMU, VMWare, SUN's VirtualBox -- being so
readily available, and allowing filesystem 'snapshots', it's
easier and easier to spin up a development operating system and
build and install directly onto the root filesystem, thus getting
a complete package.
Upgrading your build scripts from slacktrack version 1.x
--------------------------------------------------------
1. slacktrack internal variables
-----------------------------
$SLACKTRACKFAKEROOT
This variable points to the location of the package's
root filesystem (usually /var/tmp/<someplace>).
Using slacktrack 1.x, you could perform operations on the
package contents from your build script *during* the build
process.
In slacktrack 2.x, the package root directory is only populated
after the build script has finished.
However, the variable can still be used from a post-build
script.
You can use slacktrack's '-R' operator to specify a post-build
script. In the example below, the post build script is
called 'postbuildfixes.sh' and resides in the same directory
as the 'trackbuild' script.
** Note: Ensure that your post-build script is chmod 755. **
# Launch the build script:
altertrack \
--notidy \
--showdeps \
-T $TMP \
-l $CWD/build.$ARCH.log \
-R $CWD/postbuildfixes.sh \
-b $PKGSTORE \
-zIKASmg \
-Ocp $PKGNAM-$PKGVERSION-$ARCH-$BUILD.tgz ./linuxdoc-tools.build
The contents of this post build script can be something such as:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/bin/bash
# Once altertrack has determined what the contents of the package
# should be, it copies them into $SLACKTRACKFAKEROOT
# From here we can make modifications to the package's contents
# immediately prior to the invocation of makepkg: altertrack will
# do nothing else with the contents of the package after the execution
# of this script.
# If you modify anything here, be careful *not* to include the full
# path name - only use relative paths (ie rm usr/bin/foo *not* rm /usr/bin/foo).
# Enter the package's contents:
cd $SLACKTRACKFAKEROOT
# OpenSP creates this symlink; we delete it.
if [ -L usr/share/doc ]; then
rm -f usr/share/doc
fi
# Incase you had CUPS running:
rm -rf etc/cups etc/printcap
# crond:
rm -rf var/spool/cron
rmdir var/spool
# perllocal.pod files don't belong in packages.
# SGMLSPL creates this:
find . -name perllocal.pod -print0 | xargs -0 rm -f
# Some doc dirs have attracted setuid.
# We don't need setuid for anything in this package:
chmod -R a-s .
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
2. Build script changes
--------------------
If your build scripts were more sophisticated and took advantage of
the way installwatch used a pseudo root filesystem, please be acutely
aware that your build script now runs on the host's live operating system;
so you need to be more careful. However, as suggested -- run only on development
installations.
3. Additional files creeping into the packages
-------------------------------------------
Due to some daemons making changes to their config files whilst your build
is in flight, you may find some additional files have crept into your package
which you were not expecting.
You may wish to turn off the following daemons before starting a build:
CUPS
crond
sendmail
ypbind (NIS)
ypserv (NIS)
If you look at the example post build script above, you can see that it
removes some CUPS and crond residue.
Whilst it would be possible to remove these paths from slacktrack's scan
locations, some users may wish their package to place data in those directories;
so you need to make your own adjustments and checks for this.
END.
|
