configuration parameter/decision archive?
nick at byu.edu
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 linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev