TITLE install-log LFS VERSION: Any AUTHOR: Andy Goth SYNOPSIS: How to manage packages with install-log HINT: (version 1.0, Dec. 17, 1901) This hint covers install-log, a simple package management tool. It discusses how to set up install-log, how to use it to make installation logs, and how to use those logs for package management. It also discusses how to use install-log during all stages of lfs installation. This version of the hint covers install-log 1.9, and the general ideas should apply to any version of lfs. In fact, much of it isn't even lfs-specific but still useful for any UNIX system that doesn't already have package management. +-----------------------------+ 1. INSTALL-LOG INSTALLATION +-----------------------------+ First, get install-log at one of the following mirrors: http://prdownloads.sourceforge.net/install-log/install-log-1.9.tar.bz2 http://install-log.sourceforge.net/release/install-log-1.9.tar.bz2 http://www.pengaru.com/~andy/packages/install-log-1.9.tar.bz2 The tarball is 10k in size, just like this hint. ;^) Then unpack, compile, and install: make && cp install-log /usr/bin && cp install-log.1 /usr/share/man/man1 && cp install-log.rc /etc && mkdir /var/install-logs && touch /var/install-logs/.timestamp And we're golden. Alternately, you can test install-log out right away. Use this variant: make && cp install-log /usr/bin && cp install-log.1 /usr/share/man/man1 && cp install-log.rc /etc && mkdir /var/install-logs && touch -r install-log-1.9 /var/install-logs/.timestamp && install-log install-log && cat /var/install-logs/install-log Instead of merely creating the .timestamp file, this sets its, uhm, timestamp to equal that of the install-log-1.9 source tree. It then runs the install-log program to take note of its own installation. Wow. And finally, it cats the log to verify its contents, which should be: /usr/bin/install-log /usr/share/man/man1/install-log.1 This is as you'd expect, except that install-log.rc doesn't show up. This is because, by default, install-log doesn't scan the /etc directory. I recommend editing your install-log.rc right away and shaping it to match your site. For instance, if you don't use /usr/local, remove it. Add /usr/etc and /usr/var to EXCLUDE (install-log is not meant to track configuration and state files, only binaries and support files that don't get touched). I strongly recommend that you add /usr/share/info/dir to the EXCLUDE list; otherwise, /usr/share/info/dir will appear to belong to _every_ package that has an info page. +---------------------------+ 2. INSTALLING OTHER STUFF +---------------------------+ This part is easy. Just install said stuff like normal, and then run install-log, thusly: tar xjvf msword.tar.bz2 && cd msword && make install && cd .. && rm -rf msword install-log msword There you go. Now, /var/install-logs/msword contains a list of every file added or modified by the installation of msword. Go ahead and cat it, vim it, or whatever. And now that you're familiar with install-log, let's put it to good use: +--------------------+ 3. INSTALLING LFS +--------------------+ install-log descends from a little script Gerard Beekmans suggested long ago, so its no surprise that it's specially designed for lfs. It can track your installation through every phase in the book. But first, have install-log ready on your system. --------- Chapter 4 --------- At the end of chapter 4, after creating the directories and symlinks, type the following: cp /etc/install-log.rc ${LFS}/etc && touch ${LFS}/var/install-logs/.timestamp Heh, did I mention to have LFS set? install-log actually depends on it. When it sees the LFS variable, it pretends to be chroot'ed inside ${LFS}. You may want to edit ${LFS}/var/install-logs, if the lfs system you're developing is to have a different layout than your current one, or if you want to use a different editor (keep in mind that in chapter 6 it might not be available). --------- Chapter 5 --------- In chapter 5, after each package you install, call install-log: install-log bash install-log binutils install-log linux And so on. For the Linux kernel, you need to do the following, or else install-log won't track it correctly: find ${LFS}/usr/include/{asm,linux} -exec touch \{} \; && install-log linux This is because all the timestamps in /usr/include/asm and /usr/include/linux are old. install-log operates on the assumption that anything new you install will have a timestamp newer than that of /var/install-logs/.timestamp. If you have to copy the old NSS library files, type the following afterward: touch ${LFS}/var/install-log/.timestamp This prevents install-log from attaching the NSS files to any of your logs. You'll delete these NSS files later on, so you don't want to mess with logging them. At the end of chapter 5, install install-log itself to ${LFS}: make CFLAGS="${CFLAGS} -static" && cp install-log ${LFS}/usr/bin && cp install-log.1 ${LFS}/usr/share/man/man1 && install-log install-log --------- Chapter 6 --------- In chapter 6 (inside the chroot), after each installation, call install-log: install-log -f bash install-log ncurses install-log glibc etc. Specify the -f option for every package that was previously installed. This includes bash, binutils, bzip2, diffutils, fileutils, gcc, grep, gzip, make, mawk, patch, sed, sh-utils, tar, texinfo, and textutils. When you call install-log after installing gcc, it will report stale files. This is because when you installed the statically-linked gcc, it produced a libstdc++.a.2.10.0, but when you did the normal dynamic gcc, it didn't. It's safe to delete this file; it's just a remnant of chapter 5 that was overlooked. Delete this file if you will, and then remove it from /var/install-logs/gcc: sed /^#/d /var/install-logs/gcc > /var/install-logs/gcc~ && mv -f /var/install-logs/gcc~ /var/install-logs/gcc Or, if you keep the file, do this: sed '/#/s/^#.*# //' /var/install-logs/gcc > /var/install-logs/gcc~ && mv -f /var/install-logs/gcc~ /var/install-logs/gcc By the time you install gcc in chapter 6, you'll have vim, so you could use it instead of sed to tweak your logs. You could use the -e option of install-log to automatically start vim (or whatever editor) on your log file. I recommend at least cat'ting each log you create to verify that it came out as expected. Well, this covers everything in the lfs book. The rest of this hint covers more cool things you can do with install-log, things that you will invariably need to do in the upkeep of your lfs system. +-----------------------+ 4. UNINSTALLING STUFF +-----------------------+ xargs rm < /var/install-logs/packagename && rm /var/install-logs/packagename ;^) +--------------------+ 5. UPGRADING STUFF +--------------------+ install-log can handle installing a package more than once. Do everything like you would normally do, except supply the -f flag to install-log: tar xjvf msword.tar.bz2 && cd msword && make install && cd .. && rm -rf msword install-log -f msword If you've already logged a package, install-log won't run on it again without the -f flag. When install-log does run, it will scan your filesystem, as normal, but it will also compare its results with the previous results. Every file in the old list that didn't turn up new in the new list is either marked "# Old #" or "# Del #". Old files are probably safe to delete, because when you reinstalled the package it didn't touch them. Del files are already gone, so just shave them out of the log using sed or another text editor. They're there to alert you of a possible problem. Note that state files, configuration files, and other files that change throughout the life of the program should never have been logged, and therefore you will have to keep track of them on your own (does msword need ~/.mswordrc anymore, or does it now use a win95 registry stored on a file mounted -tvfat -oloop?). +------------+ 6. CAVEATS +------------+ install-log is a very simple and naive utility designed for little more than creating lists of new and modified files. As such, it can't handle things that continually change, like configuration files. It also can't handle files shared between packages, like /usr/share/info/dir or a BSD-style init file. It can't handle packages that install files with any timestamp other than "right now". Sometimes you need to tweak its output a little bit, by touching the installed files (see Linux example above), aging /var/install-logs/.timestamp, and/or editing the resultant log. And you had better be sure of your dependencies before you xargs rm something. But nine times out of eight, it works. +-----------------+ 7. FUTURE PLANS +-----------------+ These won't get implemented unless I run out of other projects or people express interest and contribute their time. But I'd like to make a 2.0 release including a greatly expanded /var/install-logs directory, giving an actual history of installations and removals, md5 sums, dependencies, installation, upgrade, and uninstallation scripts, download urls, package information, and about everything else you'd expect in a full-blown package tool. It'll also have builtin functions for installation, upgrading, uninstallation, querying, verifying, and downloading updates. You'll be able to ask it to check the files on disk against the md5 sums and issue warnings on discrepancies. You'll be able to ask it to get the latest of something and, assuming that it (or you) can find where to download or how to install, it'll... install. I think this thing has potential, but I also think it has a lazy maintainer. ;^)