Perception of LFS

Matthew Reppert repp0017 at umn.edu
Tue Jan 14 14:40:21 PST 2003


On 14 Jan 2003, Gerard Beekmans <Gerard Beekmans
<gerard at linuxfromscratch.org>> wrote:
> On January 12, 2003 03:48 am, Greg Schafer wrote:
>
> Back to what we can do to enhance the perception. Other than writing the
book> 
> in technical sound way and not spreading around bullocks in the book I
can't 
> think of anything else we can do. Market the book in hopes that famous
Linux 
> people hear of it and actually try it out?

You know, there is one thing I'd like to suggest, although it may open up a

new field of issues. Currently, I doubt there are many distributions that
take
a package straight from the distribution tarball, compile it for an arch,
test
it to make sure it doesn't blow up, and stick it straight into their
package
database. Instead, many packages end up having that familiar "-number"
addition
to the end of their version.

This is because, of course, the distributions go and patch up bugs in stuff
they release. We do, but I know in the past we've missed a couple of
important 
things, namely in our toolchain. My reference for most of this is Debian,
since 
it's what I've used in the past  ... their current 2.95 gcc is 2.95.4 
(prerelease), which is based off of the Oct. 6 gcc CVS. Against that, they
have
18 patches for Linux-i386 to build C, C++, and Objective C. Now, a few are
trivial, like "change the version to 2.95.4 Debian prerelease" and "fix up
doc 
filenames to install like Debian wants", but there are still 8 patches that
seem
fairly important. One of them fixes the gas .hidden detection issue we were

having with 2.95.3. Another one fixes a bug in the strength reduction 
optimization, which *is* included in the -O2 optimizations and fails
noticeably 
with a simple test case on powerpc.

Now, my last LFS system (before the one I'm running right now) was built
about
two months before Alan's comments. When I read it, I thought about things
for
a while and decided I'd basically use Debian's source packages for gcc and
benefit from their QA. (Note, this is just my solution. It was a pain
figuring
out how to patch up my compiler "just like Debian's" the first time without
the benefit of Debian development tools.) The system I just built last week
runs
gcc 2.95.4 as a result. I also grabbed some 3.2.1 patches from them (there
were 
only 6 that their makefiles said applied to my platform, but there are 42 
patches in the patch directory). My point is, I can see how our toolchain
could 
get subtle little bugs. Subtle little bugs can play hell with the kernel.

Now that I've rambled for a page or more about this, what can we do about
it?
Well, I guess that's open to debate about a few things. I noticed that a
few
people here are keeping tabs on some of the project mailing lists, and I
think
that's a good thing. Personally, I think it'd be great to have people keep
tabs
on things like that and forward patches to the book. (For critical
problems, is
it possible to change the current release of the book to add patches?)
Really,
the most important things in this respect are probably gcc, binutils, and
glibc,
since they're probably the things that 1) will screw you over the most if
they
break, and 2) are complicated enough to make breakage that more easy (this
is
a subjective observation). Oh, and the kernel, to some extent; now that I
think
about it there was a nasty ext3 journal=data bug that only recently got
fixed.
The problem with this is that it can take time to keep up with this stuff, 
especially when we're dealing with high-volume mailing lists. So I'm not
sure
how much we can realistically expect. Of course, if our policy is just
"wait
until releases fix things" it doesn't matter as much, but (for example) we
had
gcc 2.95 in for so long that I think it would have been nice to have a note
that
said something like "This bug has been noted, here's a patch that's not in
the
official FSF release yet". (I only found out about this in particular
recently
though ... )

Comments? Good idea? Waste of time? Good idea but perhaps too much on our
current resources? Or am I just blowing out so much hot air? 
(I've interpreted some of what Alan has said about "running the latest and
greatest off gnu.org" as having to do with this sort of issue .. )

(By the way, on a totally unrelated note, if I come up with something I
think
should go in the book, this is the place to go, right?)

Matt

-- 
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 mailing list