Le Wed, 29 Nov 2006 23:55:28 +0000 Reece Dunn <[EMAIL PROTECTED]> a
écrit :
> > From: [EMAIL PROTECTED]
> > Tapio Kelloniemi wrote:
> > > On Sun, Nov 26, 2006 at 09:25:18AM -0500, Chris Staub wrote:
> > >> No, it's not - it is completely unnecessary. $LFS/sources is only
> > >> mentioned once in LFS (well, ok, twice...), and even then it's really
> > >> just a suggestion - the source directory could be anywhere and called
> > >> anything you like, and no package instructions in either LFS or BLFS
> > >> refer to any source dir specifically anyway.
This could be one more reason to unify the unpacking and buid
instructions !
> > > What about this (just one example among others). This command can be found
> > > from the SVN LFS book in one of the GCC sections:
> > > patch -Np1 -i ../gcc-4.1.1-specs-1.patch
>
> I don't think that it is too hard to understand that the path to the gcc
> patch should
> point to where it is located on your system. If you can't grasp that, should
> you really
> be building LFS?
Djezus, what did I start ! Listen guys, I didn't want to engage in such a
war, and frankly speaking, I don't understand why you are so aggressive
about this idea. You like it or you don't like it, and I'm OK with that.
But why being rude with someone trying to better explain the point of a
silly french user speaking pidgin english ?
"If you can't grasp that, should you really be building LFS?" !!! Listen
to you ! You should be ashamed. The point was totally different. Putting
all the sources in a directory and unpacking in this same directory is
not very practical, so I was proposing something different. I currently
use the simple way of copying what I need in the /sources directory, but
I think it could be a little more automated in the book. You don't like
it, fine. You explain to me why it is not a good thing for the project,
even better. But arguments like "I do things differently, so I think what
you propose is silly" are in my point of view irrelevant.
> > > This command is to be executed in the gcc-4.1.1 directory and the command
> > > works if, and only if, the patch file is in the directory just above
> > > this gcc-4.1.1 directory. I never have built an LFS system, where I could
> > > have used this command as it is in the book. IMHO all commands that often
> > > need modification, should be marked as such, eg.
> > > patch -Np1 -i [your source directory]/gcc-4.1.1-specs-1.patch
>
> I think that would complicate matters. All that is required is a line when
> discussing
> the $LFS/source directory is to say something like "This book assumes that the
> tarballs are extracted in the $LFS/source directory." That way, the LFS book
> is
> consistent.
>
> If you really want, you can add something to the effect of "You can choose to
> place
> the source files in a directory of your choosing, but you need to adjust the
> paths
> accordingly." However, I think that this is too much. I would put it under the
> category of "things you need to know and understand before reading the LFS
> book".
Once again, it's not a matter of knowing what has to be done for the
patch to be correctly used ! I've built about a dozen LFS system, I know
how to apply a patch !!! And if I don't, I know how to look in the man
pages. And everyone building a LFS system is aware of that, I think !
It's just a matter of automating things a little more !
> > > The LFS layout, where all patches are in ../ is not very practical, since
> > > in directory listing source directories get buried under the names of
> > > package
> > > and patch files. It also makes it impossible to delete the gcc tree like
> > > this:
> > > # rm -rf gcc-*
>
> So don't put them there. There is nothing preventing you from using a
> different
> layout if you don't like the way that it is organised. I am grouping the
> sources
> into subdirectories named after the package, as I am keeping the LFS, BLFS
> and other package sources so I don't need to download them each time. But that
> is just me :).
Again, not the point.
> > Then unpack your source tarballs wherever you like. I still see no
> > reason to change what's in the book, as I do have all the source and
> > patches in one dir and have no problems doing it that way. Besides, why
> > would you need to use "rm -rf gcc-*" to remove the GCC source and build
> > dirs? It's not that difficult to add the extra "4.0.3" or "build" to the
> > dir name (or use bash's tab completion to make it really easy). Don't
> > forget you could also use "tar tf" to list the files in a tarball, or
> > "tar xvf" for a verbose listing that tells you exactly what's being
> > unpacked and what directory it's all going into.
I think everyone knows how to use bash completion, thanks !
> I use a perl script that does the same thing as:
>
> cd /build
> tar -xf /packages/$PACKAGE/$PACKAGE-$VERSION.tar.*
> cd `ls`
>
> /packages/$PACKAGE/$PACKAGE # run the build script
>
> cd /build
> rm -r *
>
> This works very well for me. It is actually a bit more complicated than that,
> but that is the general idea. When applying a patch, I refer to it explicitly
> as /packages/$PACKAGE/[...].patch.
As pointed by another lecture^H^H^H^H^H^H^Hmail, your knowledge of Unix
habits is far from perfect, so don't consider you are the only one
knowing how to use it !
> > Adding a $SOURCEDIR variable where none is needed is just adding another
> > level of user hand-holding to the book (and there's already enough as it
> > is). I do not see any point to changing the instructions.
There I see something that is worth a little explanation. I don't read
ALL the mails from thoses lists, so maybe I missed something. Is it a
widely shared impression from the "LFS bosses" that the knowledge of
books users tend to diminish to the point where the calls on the lists
show that people couldn't handle one more variable ?
> I agree. The instructions are clear as they are.
> LFS User: 17921
I too have a number, but can't remember what it is. And LFS site still
down :-( So, all I can say : first LFS system : 3.0 ;-)
\bye
--
Nicolas FRANCOIS
http://nicolas.francois.free.fr
A TRUE Klingon programmer does NOT comment his code
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
