[blfs-support] blfs-support (no subject)

Simon Geard delgarde at ihug.co.nz
Wed Dec 26 18:17:04 PST 2012

On Thu, 2012-12-27 at 01:57 +0100, Tobias Gasser wrote:
> Am 25.12.2012 10:28, schrieb Simon Geard:
> > Hmm... it occurs to me that while using FS monitoring (or your 'find'
> > based approach) is neat, it's not parallel-safe. I'm guessing you don't
> > install more than one package simultaneously? My current build scripts
> > basically consist of a generated Makefile to deal with dependencies, and
> > it copes quite happily with being run with half a dozen processes...
> i first used a 'find' aproach.
> fine for lfs. but after having installed xfce it gets really slow.
> so i switched to an inotify approach. but not for long. very buggy as 
> files can't be monitored as long as the path is not registred. so i 
> missed lots of files which were installed but not logged...

For me, I think the biggest problem would be the inability to build and
install multiple packages at once. With my old build scripts, I used to
build individual packages with -j6, but found that just meant I was
spending all my time waiting for configure scripts to run
single-threaded. Especially for something like Xorg with it's many small
packages, being able to build a dozen packages in parallel helps a

> now i use destdir for everything.
> i create 2 tempfs for each package. one for the extracted sources (and 
> build if required), one for the destdir. as i have 16g of ram in my 
> build-system, this even works for libreoffice. no need to remove the 
> sources, just umount the tempfs. miliseconds to remove the libreoffice 
> source.

Does the tmpfs really help that much? Last time I tried it, I didn't see
much of a speedup from building on tmpfs vs on the regular disk - a few
percent at most. I suspect that OS-level disk caching is keeping most of
the activity in-memory anyway...

> and the destdir (tempfs mounted on pathes build with mktemp) is the only 
> one of these 3 which works with parallel builds.
> most packages support destdir or something equivalent. only a few 
> packages require some nasty patching...

For that reason, I've dropped most of the bits in LFS that move stuff
between / and /usr after running "make install". I'm never going to have
them on separate partitions, so it's just added complexity. Actually, my
current system just has /bin, /sbin and /lib symlinked into /usr now

> to automate things like user-creation i use a _pre.sh, to fix up config 
> files i use a _post.sh. the destdir and those 2 scripts i put into an 
> tar.xz and have some kind of simple package management which allows to 
> update mulitple systems with one build. removing the 'old' version first 
> is peanuts: just get a list of installed files from the old tar.xz. (ok, 
> i have to manually save the configuration stuff first.. it's not really 
> package management, but makes life much easier)

A little more complicated than what I do, but then, I don't care about
copying stuff to other systems, only about being able to remove packages
I no longer need. So stuff like user creation can be done as part of the

> the kernel i don't build with destdir. as i need the sources for some 
> packages, there is no saving in building in ram and copying to disk 
> after install - and the kernel differs on each machine so i can't 
> distribute updates.

Same here... that one's a special case, keeping multiple versions
installed, and not removing the source tree after build, etc. Plus,
uninstalling a kernel is easier than most most packages, since
everything is in either /usr/src, /lib/modules, or /boot, and is clearly
tagged with the version...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-support/attachments/20121227/57ba82cc/attachment.sig>

More information about the blfs-support mailing list