| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On Sat, 2023-08-26 at 01:55 +0000, super1337 wrote:
> Greetings, everyone!
>
> I've completed a handful of LFS builds over the course of time, as
> well
> as a few successful jhalfs and the preceding script as well. I'd
> like
> to take a few minutes to voice some thoughts I have.
>
> First and foremost, I thank each and every contributor, no matter the
> scope of your involvement, for keeping the project going. With so
> many
> things now moving to containerized software packages, and traditional
> package managers are starting to spin uncontrollably on the bloat
> boat,
> I feel like LFS is extremely important. For the love of goodness,
> don't
> give up! (A wonderful article on jmmv.dev entitled "Fast Machines
> Slow
> Machines" explores the problems of the current development paradigm
> very
> well.) Truly, thank you.
>
> On to some suggestions. Please understand that I haven't taken the
> time
> to try learning how the jhalfs script works, and some suggestions may
> be
> unreasonable.
>
> 1) when I first move into the jhlfs directory and issue make, one of
> the
> first menu options to configure is which version of the book to
> build.
> However, I don't understand how to pick a specific version using the
> information that's provided. It would be far more clear if a user
> could
> put in a version number, or have an additional xml file to download
> to
> the root of the jhalfs directory
There are three items in "BOOK Settings" that allow all that:
"Use BOOK": allows to choose between LFS Sysv, LFS systemd, or BLFS.
"Book version": allows to choose between using a git clone or an
already downloaded working copy.
Depending on the preceding, either:
- if using a git clone: "Branch, tag, or any commit": allows to specify
any git reference (a tag, a sha, a branch head, ..., anything that can
be provided to "git checkout")
- if using a working copy: "Loc of working copy (mandatory)": allows to
specify the full path to an xml (that can be a previous git clone,
modified by user). linuxfromscratch.org does not provide directly xml
files without using git.
I agree that it may be not that clear. If you have some ideas to
improve help and or labels, please tell us.
>
> 2) xml files are the next thing on my mind. As I recall, there is an
> option to use a supplied XML to work from. Would it be an issue to
> have
> a list of such files directly on the alfs -> downloads page?
>
As said, the linuxfromscratch.org site does not provide such files, but
they can be retrieved with git.
> 3) bootable media is something that I dearly miss. download the iso,
> boot it, and now you instantly have everything you need right in
> front
> of you to build the system. I have an i586 beside me that is begging
> for a LFS build. As it is, I need to install debian jessie on it,
> compile a new kernel, do some upgrading, and now it's able to compile
> a
> current LFS. Having an ISO to download that's built on a 586 would
> be
> quite the boon! Please correct me if I'm wrong, but I'm of the
> understanding that running something build on 586 libs will work, and
> produce correct objects, for modern arch's.
>
Not really an "alfs" subject, but why not use any of the live distros
on the "market". I'm sure it is possible to find archives of those that
work on i586.
> 4) a single tar file that includes all patches and sources would also
> be
> a big benefit. I see that at some point in the past week or two,
> someone updated the zlib1.2.13 link. I found myself very frustrated
> trying to find that version elsewhere, and then to get the script to
> just accept the version I manually downloaded. I've had to hunt down
> sources in the past, but never got as irritated as I did with zlib.
>
As far as using jhalfs, put the downloaded file in $SRC_ARCHIVE, and it
will be used.
Again, documentation can certainly be improved here, so please propose
changes.
> 5) while the build script is running, it's very clear which package
> is
> being built, and how long it's been running. Personally, I'd like to
> see
> something of the following nature:
> ____a) after the ch5 binutils SBU has been time'd, the other handfull
> of
> the toolchain lists the first SBU time - and does the math for the
> approximate build time of {current} package
> ____b) each of the handful of the toolchain is also time'd
> ____c) when ch5 is complete, the SBU is re-calculated
> ____d) moving though chapters 6,7, and 8 the SBU value and
> approximate
> build time is displayed using the recalculated average of all of ch5
> Benefit being here is to hopefully have a more accurate SBU
> presented,
> and to give the impatient human behind the screen a very reasonable
> estimation of when to come back and check on things.
>
I think a) + d) would be a useful addition: displaying the estimated
time based on book's SBU figures, knowing the base (standard) SBU from
binutils-pass1. For b) and c), I'm not sure I understand what you mean.
The base SBU is only from binutils pass 1 and cannot be recalculated
from other packages in chapter 5.
> I should probably conclude my first email at this point, before I
> write
> an entire volume.
>
> Once again developers, what you are doing in this project IS very
> important.
> Thank you so much.
You are welcome.
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page