Should the build commands be reinstallable?
gschafer at zip.com.au
Sun Jan 4 15:45:57 PST 2004
I know we do take this line in some circumstances, e.g. the coreutils
hostname patch, but what about in general?
Currently, there is a bunch of packages that fail to reinstall when using
the book's commands, mainly due to use of "ln -s" instead of "ln -sf".
There's also a couple of "mkdir" 's instead of "mkdir -p" 's as well. And
lastly, bzip2 refuses to reinstall unless a "rm -f /usr/bin/bz*" is slipped
in before the "make install".
Of course, there are some sections early in Ch 6 where reinstallable
commands don't really make sense, e.g. changingowner, creatingdirs, proc,
So should we have an official policy on this? It's easy enough to make the
changes but do we really want to? A downside to the "ln -sf" 's is that the
first time reader may not see an error that would otherwise show up if they
made a typo.
Anyway, just thought I'd throw this up to the list to see if anyone has some
PS - I've developed a testing tool (essentially just another plain old build
script) which builds LFS directly from the XML source using lfscmd output.
It works surprisingly well and is what brought the above to light. I've
integrated my ICA (Iterative Comparison Analysis) routines so the potential
for testing various build scenarios is huge. I'll add some polish and put it
up soon for interested folks to check out.
More information about the lfs-dev