r8518 - in trunk/BOOK: . chapter01 prologue

[Bruce Dubbs]

Sukucorp Sukucorp wrote:
> On Sat, Apr 12, 2008 at 5:28 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>>  I'm not sure why.  The changes I added only say to change some (three) symbolic
>>  links or add them if they don't already exist.   These changes to links can't
>>  really hurt and it establishes a better base configuration from which to build
>>  LFS.
>>
>>  The unsaid implication here is that if a user doesn't know how to change a
>>  symbolic link, then they are not yet ready for LFS.
>>
>>  Resetting the links by a user is just as trivial as making them.  The only real
>>  change I can see being made on the vast majority of systems that need any change
>>  at all is to change /bin/sh to point to bash.
>>
> 
> This is not about whether a user is competent enough to change
> symlinks, it is about whether the user needs to update the symlinks on
> the host. With the change you changed the minimum host system
> requirements to something more the absolute minimum. The change
> implies that if /bin/sh is a link to /bin/dash or if /usr/bin/awk is a
> symlink to /usr/bin/mawk then LFS cannot be bootstrapped which is
> simply not true.

No, I didn't change the host requirements, I changed the configuration. 
Something quite different in my opinion.

We had a discussion about this in:

http://wiki.linuxfromscratch.org/lfs/ticket/1962

and although that got resolved, I was trying to head off potential future 
problems.

See also the thread starting at:

http://linuxfromscratch.org/pipermail/lfs-dev/2008-April/061181.html

In the general case, there *may* be problems with mawk for gawk, byacc for 
bison, or dash or some other sh variant for bash.  We don't test them all, so we 
can't be sure the others work or not.  We do know that if those symlinks are 
made, then these potential issues are taken out of the loop (if the user follows 
the section, which admittedly many times is ignored).

Also, bashisms tend to creep into many scripts.  I really don't have a problem 
with that as long as the header is #!/bin/bash and not #!/bin/sh.  However, 
upstream developers don't always do that.

We don't know in advance all the host systems the users may choose, so heading 
off potential problems is proactive.

   -- Bruce