configuration parameter/decision archive?

Nicholas Leippe nick at
Tue May 13 12:28:34 PDT 2003

On Tuesday 13 May 2003 01:11 pm, you wrote:
> I'd be interested in helping out with this (after the next few weeks are
> out of the way) and have some webspace available to host everything on. 
> One personal opinion though - I hate Wiki's.  Well actually that's a bit
> strong - some wiki's I've seen just seem to sprawl and it becomes very
> hard to find the information I'm looking for.  I'd prefer a much more
> structured document.

Well, sure.  Any document can become unwieldly if not cared for.  The reason 
I suggest a wiki is so that more people can easily contribute--and updates 
can be made right as they are found.  In my experience, if I'm reading 
through notes/email threads/howtos and I find something important that wasn't 
documented, if I have to jump through hoops to get the doc updated, I usually 
don't bother--I just keep my own private set of notes for myself.  This means 
that noone else benefits from my knowledge and must discover the same for 
themselves the hard way all over again.

There may be other ways than wiki to achieve the same effect--perhaps 
something like php's user-commented online docs?  This might allow some 
tighter control of the contents of the main doc--and we could refactor the 
comments into it occasionally to keep it concise.

>  I think this could also tie into related things
> like ascertaining both compile-time and run-time dependencies and files
> installed.  i.e. when a new version of a package is released I am
> envisioning running three scripts: 1) The install script 2) Dependency
> analyser 3) file tracker (i.e. install log/package manager type thing). 

I'm not too concerned about automating things, but I agree it would be very 
nice to have a complete reference of each package's dependencies and 
installation results.  (Not just the files they install, but where they 
expect to find other things, how they search for their dependencies, etc. so 
we can easily remember what we have to tweak to have our way with it.)

> The only way I can see of maintaining the most suitable ./configure
> flags and such like is by manually inspecting output like ./configure
> --help the CHANGELOG and related stuff to see whether any changes to
> the instructions are required.

Yes, this necessarily must be done for each new release of a package, but I 
see no reason why more than one person has to do it--if the first person 
makes a new page for that release and documents the changes, or that it has 
no differences, then no one else has to do so.

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