On 13/03/2017 03:09, Bruce Dubbs wrote:
Pierre Labastie wrote:
After eight years of rolling release, the jhalfs development team is
pleased to announce the release of jhalfs-2.4-rc1. It is a
preliminary
release of jhalfs-2.4. Uncountable changes have been made since the
last version. The main new features are the ability to use a package
manager (provided it can use "DESTDIR install") and the ability to
install tools to build BLFS packages.
This release is compatible with the (B)LFS books in the 7.x
series, as
well as with the recent 8.0 versions and the current SVN, both SYS V
and systemd.
You can download a tarball from [1] and see the list of supported
books at [2].
Please, test thoroughly, and send any comments or bugs you find
to the
alfs-discuss mailing list.
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!
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)?
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.
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.
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).
========
That's about all for now. Thanks for all your hard work so far.
Thanks a lot for your input.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
