configuration parameter/decision archive?

Nicholas Leippe nick at
Tue May 13 01:08:35 PDT 2003

Every time we go through a new iteration of LFS, we go through all the 
options on many of the packages trying to figure out how to tweak them 
appropriately.  I'm curious, has anyone documented what they've learned 
somewhere to make this easier each subsequent time through?

I'm thinking of something like this:

Package XYZ:
./configure --help options:                         LFS notes
--prefix=          configure --help text            still copies file Z
                                                    to /sbin/z

--enable-foo       configure --help text            This misses file X
                                                    and needs pkg Y

CFLAGS                                              is ignored by

This package links with foobar by default, but library search path is
hardcoded in  Whatever...


Options that don't deviate in any way from the expected at all could be 
ignored-or for completeness listed w/DWIS (does what it says) or something as 
comment.  (blank comment doesn't help--that's ambiguous)

I know this could potentially be a huge undertaking, but several LFS users 
have taken copious notes several times through.  I just can't help but think 
that doing this level of detail once would go a long way to saving time in 
future revisions when something is misbehaving.
I know it's not that hard to search the lists for prior threads hashing over 
some package w/issues, but it would be handy to have a consolidated place for 
it all.  Perhaps a wiki web--that would make it hardly painful at all since 
everyone could contribute as they find things--keeping all the learned wisdom 

We could do one page per package (that discusses the differences between 
versions and why version X was chosen or the tradeoffs), and one page per 
package-version w/details.

This may sound like a new version of the book, but it's not.  It's just the 
book's research notes, really--and we all know that research notes are far 
more voluminous than the final publication.  The book is the streamlined 
result of combinations that work.  

Or is something like this already in place?  Point me to it if that's the 
case.  If not, does this idea sound too difficult?  Of too little usefulness?

I guess in summary, I'm suggesting we post the results of our discussions in 
a single location so it's easier to find what was considered and why 
decisions were made--and that a wiki web would be an ideal method for doing 

(irc: kamikaze)
Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list