Pierre Labastie wrote:
On 13/03/2017 03:09, Bruce Dubbs wrote:
Here are some issues I've found. Most minor, some not. I the order I
noticed them:
1. BOOK Settings.
a. Loc of working copy (and other items requiring directories)
should be indented to the first letter of the parent. For example:
Release (Working Copy) -->
(/home/bdubbs/LFS/trunk/BOOK) Loc of working copy (mandatory)
Would look better as
Release (Working Copy) -->
(/home/bdubbs/LFS/trunk/BOOK) Loc of working copy (mandatory)
agreed, although I am not sure how to fix that: it's deep in the
menuconfig code!
I'll take a look and see what I can find.
b. The Directory Root for BLFS is relative to General Settings,
Build Directory. It could be made absolute like all the other
directories or specified as relative. The problem with relative is that
the specification for the build directory is on a different page. I'll
note that it is an absolute directory in chroot, but that's not obvious.
Good point. Would "Directory root (absolute in chroot)" be enough (with
some explanation in the help)?
The problem here is that the tool might be run on the LFS host (e.g.
Debian or prior LFS build) or on a current LFS system needing upgrade.
I'd say that if the directory specified is absolute, then it should be
considered on a host like jhalfs for lfs. If it is relative, then it
should be relative to the Build Directory.
The comment should be to 'See help for details.' and this explained in the
help page.
2. Scripts.
a. At the start of the scripts, the tarball is checked in
$SRC_DIR/$PKG_DIR and downloaded if necessary. That works. However the
build directory is always there also. I suggest a new value $BUILD_ROOT.
I suppose this could be relative to the chroot value (/mnt/lfs) but blfs
builds really do not need to assume chroot.
Not sure I understand that part: do you mean you would still be working on
the host where you built LFS, prepending /mnt/lfs to DESTDIR install, and
so on? In any other instance, I'd say that all directories in the blfs
tools are absolute, whether being chroot'ed or booted.
You are making the assumption that the tarball is extracted into the
directory where the tarball resides and the package built there. The
extraction/build should occur in an arbitrary directory of the user's choice.
I guess $BUILD_ROOT (or whatever it is named, see below), and actually all
the dirs need to be absolute.
BUILD_ROOT=/home/bdubbs/build
would be a good example. Then before the extraction, do
mkdir -p $BUILD_ROOT/$PACKAGE
cd $BUILD_ROOT/$PACKAGE
Then the tar expansion should be
tar -xvf $SRC_DIR/$PKG_DIR/$PACKAGE > unpacked
I'm not sure what the aim was here (Manuel chose that layout, I think).
I'd say that SRC_DIR is closer to your BUILD_DIR than to a real sources
archive. I agree that there is no necessity to store tarballs at two
places, and that they should only be stored in SRC_ARCHIVE. What is not
(yet) implemented is the possibility to have subdirectories in SRC_ARCHIVE
I'd say your layout is slightly better. We could also have options to let
the user choose whether she or he wants to have $PKG_DIR in build and/or
archive dirs.
That may be OK, but I really need to see that in practice.
b. At the end of each script is:
cd $SRC_DIR/$PKG_DIR
rm -rf $UNPACKDIR unpacked
The rm -rf $UNPACKDIR should be made optional via a variable. For
instance:
cd $SRC_DIR/$PKG_DIR
if [ "x$DEL_SOURCE" = "x" ]; then rm -rf $UNPACKDIR unpacked; fi
Sure, that's an easy one, I think. Is it OK to have the variable in
envars.conf? (it's slighly more complicated to have it in the config menu).
We can have it in envars.conf for now, but eventually it would be better
to put everything in that file into the config menu.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
