Hello LFS-dev World!/n

Bruce Dubbs bruce.dubbs at gmail.com
Sat Feb 20 13:55:58 PST 2010


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.

> 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.

> 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



More information about the lfs-dev mailing list