Modification to patch/copy commands

[gerard@…]

When applying patches and copying files like the udev config files, the commands in the book assume the files are located in the top-level directory.

Since earlier in the book we assume files are stored in $LFS/sources we might want to default to that in the book too (either /sources/ or /usr/src/sources/ which might be more common).

If not, make the book consistent. Chapter 6's Glibc installation instructions list "tar xjvf /sources/" (was added as such during the branch sync from unstable to testing).

[jeremy@…]

The use of the .. in patch names and such arises because we assume all tarballs and patches are in the same directory, be it /mnt/lfs/sources or whatever the case may be. When a package gets extracted, and we cd into it, it's known that our patches are one directory level down from where we are currently. Both LFS and BLFS books use this type of structure, and personally, I think it would be better to adjust glibc to match the rest of the book - that way, we're agnostic as to where the sources exist.

[Matthew Burgess]

Agreed, I really should be more careful with my updates. I'll change that command to 'tar xjvf ../glibc-linuxthreads-2.3.4.tar.bz2', bringing it in line with the rest of the commands in the book.

[Matthew Burgess]

We'll need to add a $SOURCES environment variable to enable the book to do something like:

cp $SOURCES/udev-config-2.permissions /etc/udev/permissions.d/25-lfs.permissions patch -Np1 -i $SOURCES/util-linux-2.12q-cramfs-1.patch tar xjvf $SOURCES/glibc-linuxthreads-2.3.4.tar.bz2

That way we don't make any assumptions about where folks' sources are in relation to the current working directory.

This env. variable will need to be added to the chapter 4 setting environment section and chapter 6's chroot command too.

[archaic@…]

In Comment #2 you agreed that ../ is sufficient. Indeed there isn't any valid technical reason to not extract from the same dir that the tarballs and patches are stored in. In Comment #3, you contradict yourself and suggest a $SOURCES variable. This seems unnecessary to the target audience.

Please advise which way you are wanting to go with this.

[Jeremy Huntwork]

As I read it, Comment #2 was fixing the error at hand, and Comment #3 was going for a more long-term solution as first suggested by Gerard where we define where the sources kept.

[Matthew Burgess]

Closing as WONTFIX. Reasons are given by Archaic at: ​http://www.linuxfromscratch.org/pipermail/lfs-book/2005-June/014955.html. Using $SOURCES as per comment 3, we'd be handholding users too much. Those not storing packages and patches in the same directory should realise why the book's commands don't work and therefore how to adapt them to their environment.