################################################################ # Document: FAQ # Purpose : Frequently asked questions # Author..: Stuart Winter ################################################################ # It's small at the moment but if I get any repeated # or potentially repeated questions then they'll be added # here. ################################################################ Questions --------- 1. My build script places files into /home, but these are not included in the package created by slacktrack. Why? 2. Do I really have to remove the existing package before building a new version with slacktrack ? 3. I want to build a package of DVD libraries and players but the players depend on the libraries being installed first. How can I build such a package with slacktrack? 4. I find that when building packages with slacktrack, a number of files are appearing in the package that do not belong there. Why? 5. What does slacktrack's --touch-filesystem-first option do? why would I need it? 6. I can't compile Perl CPAN modules via perl -MCPAN -eshell Why ? 7. I'm using Slackware v13 (or greater) and I want to create package files using one of the other compression methods. How can I do that? 8. After completing a build using slacktrack, I see "You have mail in /var/mail/root" but I have no new email. Answers ------- Q1. My build script places files into /home, but these are not included in the package created by slacktrack. Why? A1. slacktrack (by design and thus default) excludes /home from being included within the package. The reason for this that typically no package shipped should ever contain data within /home. Q2. Do I really have to remove the existing package before building a new version with slacktrack ? A. No (see my zlib example), but in the majority of cases, I'd advise that you do. The reason that my example trackbuild scripts remove the existing package first (or bomb out) is because some package installations (makefiles) will not install a new file onto the filesystem if it's identical to the one in the source archive. This means that slacktrack will not notice any change in the before and after picture of the filesystem; thus your resulting package may be missing some files. The way to work around this is: 1. removepkg the package prior to building; 2. Use the --touch-filesystem-first option; But this option is not recommended since it destroys the time stamp information on your system. This option should only be used by experts using a disposable OS installation. Please see FAQ question 5. It's worth noting that Slackware's 'removepkg' program won't always remove all files (especially config files which are packaged as /etc/file.new and are renamed to /etc/file by install/doinst.sh). It shouldn't be too much of an issue though. If it's a brand new piece of software that you are building from scratch then installwatch will pick up all new files. If you're rebuilding a Slackware package using a .build script from the source tree then it's worth browsing the package's contents ( # cat /var/log/packages/lftp-* for example ), then running 'removepkg' and looking at its output. If there are any remaining config files then either move them to a safe place or delete them before building your package with slacktrack. In general though you shouldn't have any problems. Q3. I want to build a package of DVD libraries and players but the players depend on the libraries being installed first. How can I build such a package with slacktrack? A. There are two ways. 1. You either write build scripts for each individual library and create packages for each. Once the packages have been built, you install them prior to building the player. You then unarchive all packages into a temporary directory and run makepkg over it. 2. Use slacktrack and build them all one after another as you no doubt have originally attempted. I have included example build scripts for a DVD library package within slacktrack's source archive. Q4. I find that when building packages with slacktrack, a number of files are appearing in the package that do not belong there. Why? A. The way that slacktrack works is that it: [a] takes a snapshot of the files and directories on the file system; [b] runs the build script [c] makes another snapshot of the files & dirs on the file system; [d] compares the two snapshots and determines the differences [e] the differences between the two snapshots constitute the package contents The problem with this approach is that other running programs can make modifications to files & dirs on the file system during the build/compilation process. slacktrack will consider these modifications to be part of the package -- slacktrack does not directly track what the build process does: it *only* compares the differences between the file system snapshots. Major culprits for this are: cups crond (running cron jobs) Window Managers and X When using slacktrack you are advised to reduce the number of processes to the minimum, and try to ensure that there are no processes running which will modify the file system during the build process. If you cannot do this then you there are a number of work arounds: [a] Using the -x (--exclude) operator. With this operator you can specify a list of paths to exclude from the file system snapshots, thus excluding them from the resulting package. [b] Use the -R (--run-after) operator. With this operator you can specify a command that will be run after slacktrack has compiled the package contents. You may wish to run 'mc' (Midnight Commander) or perhaps just a 'bash' shell; this will enable you to inspect and modify the contents of the package prior to it being turned into a package file. Q5. What does slacktrack's --touch-filesystem-first option do? why would I need it? This option touches all files this pre-set location on the host's filesystem: /opt /bin /boot /dev /etc /install /lib /sbin /usr /var It *excludes* by default '/lib/udev/devices' since this contains live device data that doesn't take kindly to being touched. You may see errors from 'touch' about certain binaries, including /sbin/vol_id because this is a symlink into /lib/udev/devices. This will touch every file within those directories, destoying all the timestamp information. This is intended to be used on a throwaway development installation that's reinstalled daily or more often. Builds will often leave residue strewn about, so don't use this on your "good" machine and think you're managing it properly. :-) The reason behind this is that if you run slacktrack and your build partially fails, then it will leave some data on the filesystem. You then fix the problem and re-try: this time the build may succeed. However, if the original data on the filesystem from the first part-failed build has *not* changed (ie if it was some static data that was copied with cp -a (preserved time stamp & ownership)) between the first part-failed build and second successful build, slacktrack will miss this data from the final package. This option updates the file stamps contained within standard package directories, therefore allowing slacktrack to detect changes (even if the data contains an *old* time stamp from 1982, it will still detect the difference). ***** This is an expert option: Please don't use this option unless you do not care about your operating system installation ***** Q6. I can't compile Perl CPAN modules via perl -MCPAN -eshell Why ? A. If you get this message: Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. the answer is to tell slacktrack to turn off logging. eg: # slacktrack -Qnp foo-1.0-i486-2.tgz ./foo.build Q7. I'm using Slackware v13 (or greater) and I want to create package files using one of the other compression methods. How can I do that? A. It is 'makepkg' from the 'pkgtools' package which handles the compression, based upon the extension of the package file name supplied to it. The compression methods & file names are: .tgz - Gzip .tbz - Bzip2 .tlz - LZMA .txz - XZ Examples: # slacktrack -Qp foo-1.0-i486-1.tgz ./foo.build # slacktrack -Qp foo-1.0-i486-1.tbz ./foo.build # slacktrack -Qp foo-1.0-i486-1.tlz ./foo.build # slacktrack -Qp foo-1.0-i486-1.txz ./foo.build Q8. After completing a build using slacktrack, I see "You have mail in /var/mail/root" but I have no new email. A. This is because you used the '--touch-filesystem-first' or '--touch-filesystem-faster' option at build time. This option has touched all of the files on the file system, which refreshes their date stamp. The mail notification system works only on the date stamp of the mail spools, hence it triggers the message.