Perception of LFS

Seth W.Klein sk at
Mon Jan 13 14:53:25 PST 2003

Greg Schafer <gschafer at> wrote:
> [....]
> Alan Cox says:
> "I get so many weird never duplicated reports from linux from scratch people
> that don't happen to anyone else that I treat them with deep suspicion.
> Especially because it sometimes goes away if they instead build the same
> kernel with Debian/Red Hat/.. binutils/gcc"

I really don't care who Alan Cox is blaming or if he's being fair
because none of that leads to any productive action.

I see a couple productive things here.

One: Alan Cox doesn't take bug reports from LFS users.

No problem. All those bug reports should probably go through us
first anyway so we can make certain that they're actually something
Alan needs to see.

However, we obviously need to let our users know this. If they already
new it Alan wouldn't be getting bug reports that we haven't seen first.
I think we need a paragraph in the books, located where it will be
read, which says to bring bug reports to the LFS lists first.

Two: The bug reports Alan gets indicate that the average LFS build
     is of uncertain quality.

Do we know why? No but we can guess at a number of reasons:

1) People do not follow the instructions. Especially with respect to
   versions and optimization flags.

   The book releases need to say that if you want to use more recent
   versions you need to use the cvs book.

   It is not satisfactory to simply say, "Don't ever set CFLAGS."
   So the book needs to include CFLAGS settings as standard. That
   allows it to say, "Use these CFLAGS settings because we've tested
   them with this package and they work, don't use any others because
   we've probably tested them too and found they don't work." It
   also allows us to ensure that they get set correctly since the
   best way varies from package to package.

2) We are unimpressed with the quality of distibutions and yet we
   instruct people to build off them.

   Perhaps this isn't such a good idea. Perhaps boot CDs shouldn't
   be relegated to the Hints.

3) We don't know and don't have people who know the internal workings
   of the packages.

   This will change as we grow. Just recently the mount maintainer
   submitted a bug report.

   As far as i know our official position was not overly receptive of
   that report and has taken no action to fix it which is not good.

   For the rest, we'll just have to dig into the package internals
   as best we can. Go Greg! :)

None of the additions i've suggested above will help if no one
reads them. We already know people don't read Chapter 2 because of
how often they post questions answered in it. I think the biggest
reason for that is that it uses a whole chapter to say what could
be said in a dozen paragraphs.

> [....]
> Does anyone care about these sorts of issues?

I think distributions are far less than ideal. I'd like to see a
world where no competent administrator would have to use one. So
yes, i definitely care about these sorts of issues.

> In a "perfect world", LFS would be an enterprise employing real life paid
> developers, and maybe then we might be taken seriously? FFS..

I'm not sure i agree with this. A person's reward is their goal.
Those who's reward is money, work to get paid; those who's reward
is good software, work to produce good software.

Seth W. Klein
sk at               
Maintainer, LFS FAQ   
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