Idea for a new appendix

Dan Garthwaite DANIEL.P.GARTHWAITE at saic.com
Fri Mar 9 10:16:50 PST 2001


+1 ( If my vote counts, last I checked I'm not in southern Florida )
Could you make the appendix link target=_new(or whatever it is) putting the
description in another window?  (If anyone ever used Samba's SWAT, think of
how nice the /help/ feature is.)

Of course, some people are just maniacally opposed to pop-up windows.
  -dan

> -----Original Message-----
> From: lfs-discuss-owner at linuxfromscratch.org
> [mailto:lfs-discuss-owner at linuxfromscratch.org]On Behalf Of Gerard
> Beekmans
> Sent: Wednesday, March 07, 2001 5:25 PM
> To: lfs-discuss at linuxfromscratch.org
> Subject: Idea for a new appendix
>
>
> Hi guys,
>
> As we all know there can be problems installing packages. As
> I'm testing out
> a number of distributions I end up getting different all
> kinds of problems
> with packages varying on the distribution. I think it to be a
> good idea when
> the symptoms and fixes to these compile problems are grouped
> together in an
> Appendix. Rather that scribling notes under every package's
> installation
> instructions like "if you have this, do this to fix it but if
> you have this
> then do this instead", I think it may be a good idea to
> provide a list with
> symptoms and solutions in an appendix, grouped by package.
>
> This will make the instructions in chapters 5, 6, etc easier
> to read, less
> 'line noise' with remarks here and there. Those sections will
> just give you
> straight forward installation commands that assume nothing
> will go wrong (ie:
> assuming you have a perfect distro that's setup properly to
> allow all the
> packages to be compiled properly). If somebody has problems,
> for example,
> compiling bash, the first thing s/he should do is going to
> appendix D (that
> would be the next available letter in the alphabet as we
> already have A, B
> and C), find the section "Static bash" and read through it.
> Known problems
> with bash is the missing libcurses.a symlink in /lib or
> /usr/lib. That
> section will then have him/her check if libncurses.a exists.
> If so, create
> the libcurses.a symlink. If not, advise him/her to install
> the libncurses
> package and then create the symlink if necesarry.
>
> This will allow for more details in fixing a problem without
> cluttering the
> installation instructions.
>
> This is one of the situations where I'm going to create that
> appendix in a
> day or two and start filling it with into unless I get a
> stream of protests
> with valid points why not to do this.
>
> One valid point I can think of is that this may fit better in
> the LFS FAQ. It
> is my opinion, however, that there is a difference between an
> FEP (Frequently
> Encountered Problems) and an FAQ. I don't think the FAQ
> should be composed of
> items that solve compile problems, but rather just deal with
> what a FAQ does;
> deal with the Frequently Asked Questions. Technically you
> could consider a
> compile problem a question in the sense of "help, static bash
> installation
> tells me xyz, how do I fix it?" It would be a valid question,
> but I still
> think it's best to include such issues in the book itself and
> thus drawing a
> solid line between fatal package installation problems and
> (mere) questions
> about <whatever>.
>
> So that said, how do you guys feel about this?
>
> --
> Gerard Beekmans
> www.linuxfromscratch.org
>
> -*- If Linux doesn't have the solution, you have the wrong problem -*-
>
> --
> Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
> and put unsubscribe in the subject header of the message
>
>


-- 
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the lfs-dev mailing list