On Sun, Sep 30, 2012 at 01:48:07PM -0500, DJ Lucas wrote: > > I also use a homegrown PM (that is compatible with the logging in > jhalfs). There should be no need to sleep after touching the timestamp. > Some packages simply use cp instead of install. Solution is 'find .' and > touch in the source tree after updating the timestamp file and before > build and install.
LOL - I tried that in general, the last time I reworked my scripts, and got _so_much_ breakage (mostly, it only *notices* when packages don't have their reconfigure dependencies present, not just autofoo, but also Python in at least one case). I repeat that my experience with find -newer has been very inconsistent in the last couple of years. Whatever, it's water under the bridge as far as I'm concerned. Now that I'm overhauling my scripts, I'm going with the list-everything, install, list-everything-again, diff-the-lists approach (my disks are *big* nowadays). I'm even going with sub-second timings instead of just using $SECONDS, although I doubt that the extra digits are at all repeatable. Whatever, even chroot has awk. At the moment, each list of files before and after is 1.4 MB in chapter 7 of LFS - so, I suspect I'll drop the old before and after logs once I move on to a later stage - otherwise I'll end up backing up way more than 2 GB of unnecessary logs for each full system build. For the moment I'm keeping the defore and after so that I have the ability to recover if I screw up during an install - worst case so far was when I forgot to log before athe install - now I do the logging from my common start/end-of-package functions. Jhalfs has never suited my way of doing things - I keep the downloads (and scripts) in /sources, which is an nfs mount for me - so I don't ever build there, I use /building. Also, I do some things differently from the book (e.g. either remove static libs, or at least hide them so that they aren't used without me noticing, and I keep the stamps and the master list of LFS packages and patches in /misc. And critically, I don't create my local XML for a change until after I've run the commands : ideally, I build a system with the change, to see what breaks in BLFS and beyond-BLFS, before I think about touching the XML. For editing in BLFS, and for looking at what gets installed by new versions in LFS (when testing them in a completed system), DESTDIR is still useful, but I've decided it isn't useful for my scripts. At the moment I think I've got the LFS part mostly done - a process of continuous improvement [ or perhaps continuous revolution ] means that I'm still going back and changing things, and I haven't yet looked at building as a regular user for BLFS. For the moment, if anyone cares about the specifics which apply to how I'm doing things, I'm using variously - in /tools (might be a bind mount while testing) find -H /tools -xdev | sort for /mnt/lfs (I create passwd and groups just before entering chroot) find -H /mnt/lfs -xdev | sed 's%^/mnt/lfs%%' | grep -v '^/logs' | \ sort and in chroot find / -xdev | grep -v '^/logs' | grep -v '^/misc'| \ grep -v '^/building' | grep -v '^/tmp' | sort If I care about space measurement (might not when testing a built or the scripts), the logs will be in /home/logs with a bind mount from /logs. And then diff -n $LOG.before $LOG.after | grep '^/' \ >$LOG.installed || true (some of my scripts don't install anything, and diff -n has 'aN M' lines amongst the files - in this restricted usage). For measuring space, I'm using du -sk -H -x /wherever : without the -H and -x things get interesting chez moi (missing /mnt/lfs/* if I'm doing a bind mount for initial testing, and looking at /proc and /sources where my scripts live - with several seconds of nfs i/o). But each to his or her own - Your distro, your infrastructure. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
