Hello LFS-dev World!/n

Nate Brown nworbetan at gmail.com
Mon Feb 22 20:55:06 PST 2010


On 2/20/10, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> Nate Brown wrote:
>> I completed my first manual LFS build a couple weeks ago using 6.6rc1,
>> and I wanted to give a little feedback to the devs.  First and foremost,
>> thank you for enabling me to finally use a version of Linux that I feel
>> 100% at home in.  LFS is the Linux distro that I've been searching for
>> for the last 10 years, and I don't think I'll ever be able to go back to
>> any pre-built distros again.
>
> Good for you.  I'm glad you like it.
>
>> I'd also like to point out a couple simple changes that I think would
>> make a good thing (i.e. the LFS Book) even better.  I personally came to
>> LFS with about 90% of my previous Linux experience being limited to
>> either the GUI, or using tools that are designed to make distros "user
>> friendly" such as "sudo apt-get install that-new-package".  I'm not
>> ashamed to admit this, because I know there are a lot of Linux users
>> just like that.  One of the things I stumbled over (multiple times) when
>> I was first starting with LFS was relative paths.  I know, I know, I
>> know, how could I possibly have used Linux off and on for 10 years and
>> still screw up something as simple as "mkdir -v ../binutils-build"?  But
>> it happened.  And it happened again when it was time to "tar -jxf
>> ../mpfr-2.4.2.tar.bz2"...  Simply adding one or two lines at the
>> _beginning_ of sections 5.4 and 5.5 (and maybe even 5.6 if you're
>> feeling generous), reminding the reader that they need to _always_
>> unpack the source code and cd into the directory _immediately_ when you
>> start working with a new package, would have saved me literally hours of
>> trying to figure out why these exceptionally detailed instructions in
>> the LFS book weren't working like they're supposed to.
>
> We did that as the first Note in 5.4. Binutils-2.20 - Pass 1 of LFS-6.6-rc1.
>

I can't believe I missed that Note while I was building 6.6rc1.  I am
glad to see
that it's there now that you point it out though.

>> Another small suggestion I have is about what I believe is an overlooked
>> gold mine of information: $LFS/sources/linux-2.6.x.y/Documentation/00-
>> INDEX.  I know, a lot of it is more in-depth than what the average LFS
>> user might need to know, but I promise you there's some good information
>> for _every_ LFS user buried in there somewhere, if they were just
>> pointed in the right direction and they took a minute or two to look
>> through the 00-INDEX.
>
> There are many, many places that similar comments can be added.  We
> don't feel it is our place to point out where documentation is located.
>   We could be asked to do the same thing for sed or perl or glibc.   If
> adding 'just one thing' is done then why not another?
>
> The objective is to explain as concisely as possible.  The discovery
> about how to use the packages is not really the objective of the book.
>

I can see your point, and I don't disagree.  Adding one comment here and
there can add up to a lot of clutter pretty quickly.  However, I still feel that
the kernel documentation goes well above and beyond what would I would
consider "very good documentation" in any other package.  But the kernel
isn't just "any other package."  It's the kernel, and understanding it is
somewhat more important than understanding "any other package" imo.

I hope I don't sound rude by asking this, but have you looked at the
00-INDEX lately to see what a formidable reference list it is?  There are
several other pieces of reference material listed in the LFS book, are they
really more noteworthy than the veritable library in the kernel source?

>> And one last suggestion I have is actually somewhat of a question too,
>> something that in hindsight would have been good to know right when I
>> started.  I have a couple third party drivers that are looking for my
>> kernal source in /lib/modules/$(shell uname -r)/{build,source}, which
>> are currently links to the now deleted (and non FHS compliant)
>> /sources/linux-2.6.32.7 directory.  Needless to say, the modules.ko
>> aren't built when the kernel source isn't found, and one of the
>> Makefiles is even polite enough to tell me that it couldn't find the
>> kernal source and abort the installation.
>>
>> I do appreciate how section 8.3.1 (in 6.6rc1) gives a warning on where
>> _not_ to unpack the kernal source, but what I think would be even more
>> helpful is a short explanation of good places _to_ unpack the source,
>> because it's worth keeping around for a while.
>
> That's a user's choice.  There really isn't a 'FHS compliant' location
> for source.   That includes /lib/modules/$(shell uname -r)/{build,source}.
>
>    -- Bruce
> --

That last response is actually almost exactly what I'd to see added to the
book.  The kernel installation sections cover WHO, WHAT, WHEN, WHY,
and HOW, in plenty of detail, but WHERE is almost completely missing.
Simply letting clueless users like myself know that "where to plant the
kernel source tree" is a matter of personal preference is good information.



More information about the lfs-dev mailing list