| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On 8/25/23 20:55, super1337 ([email protected] via alfs-discuss Mailing List) 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
I'll let Pierre answer some of these, but I can contribute. The version of the book
referenced is either sysV or systemd, not a specific release. The main reason for
jhalfs is to automate development.
> 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?
You really need to do a git checkout of the xml.
$ git clone https://git.linuxfromscratch.org/lfs.git lfs-git
After that you can change to that directory and update it with 'git pull'
> 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.
>
> 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.
For LFS, see http://ftp-osl.osuosl.org/pub/lfs/lfs-packages/*.tar
There is no equivalent for BLFS for all packages, but all the packages are at
http://ftp-osl.osuosl.org/pub/blfs/
> 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.
The SBU is only an approximation. It is meant to just give you an idea about how
long it will take to build a package relative to the first binutils. It depends on
your hardware. I think it is a success if your SBU numbers are within 10% of ours,
but at times they can vary a lot more than that.
-- Bruce
> 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.
>
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page