Perception of LFS
kelledin+LFS at skarpsey.dyndns.org
Mon Jan 13 16:57:44 PST 2003
On Monday 13 January 2003 04:53 pm, Seth W.Klein wrote:
> Greg Schafer <gschafer at zip.com.au> wrote:
> 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.
Agreed. We need to at least see it on lfs-support, because at
the very least we can figure out how reproducible the problem
> 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.
Needless to say, a lot of this can be caught by observing the
above guidelines about lfs-support.
> 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.
Can you produce a boot-CD capable of booting off of _any_ system,
_any_ configuration, that Linux might support? My main system
can't even boot from a CD due to the jacked arrangement of two
SCSI BIOS extensions and no IDE disks. Of course, I can boot
off a floppy and load a CD that way, but you get the
point--there will always be some configuration that can't boot
off our stuff but can boot off some obscure distro like Undead
Linux or the like.
Probably the best thing to do is say, "we recommend bootstrapping
from this LFS boot-CD image, built from the most recent stable
LFS book. If you can't use that, we recommend one of the
> 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.
Part of the issue is, many of us haven't even heard about this.
Stuff like this will often escape our radar unless it hits
BugTraq or someone from our userbase reports it in
bugzilla/mailing-lists. If a bug doesn't hit either one, then
is it really serious enough to warrant our attention? When it
morphs into a new stable release, it will probably make it into
the book anyway.
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
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