The biggest issue is updates. There is no packaging setup . Updating all those packages just because of one library update seems like a daunting task. That is why I gave up on Linux From Scratch. If they had a better section on trying to implement one of the common ones available, then I would consider sticking with it.
2 Likes
I agree. Updating is hard work.
Packaging is out of the scope of the LFS book, though it does give some ideas. Part of the fun for me is getting to choose what I want to do about that.
I’ve used RPM and YUM for my package management solution (since I knew Red Hat better than Debian). I have to write all the Spec files myself, but when i’m done, i’ll have a personal repo.
My LFS build scripts, along with some RPM Spec files for LFS and some BLFS packages are on my gitlab. Samuel / LFS 8.2 · GitLab
Maybe you’ll find something in there useful.
2 Likes
As expected Linux From Scratch 9.1 has been released!
In the previous six month release cycle a number from our community were doing builds. I am not on the telegram group so did not keep up, but did post my own progress…
So… back to square one for me on the new build. I will let you know when I get beyond the stage reached on my 9.0 build, but I don’t expect to restart for a couple of weeks yet.
If anyone else’s building 9.1 keep us posted please 
1 Like
I got my 8.2 build scripts out over the weekend and worked out the kinks and rebuilt it. Time to update it for 9.1.
1 Like
I would disagree packaging is out of scope. There are now just too many packages to try to keep up with, and they keep growing by leaps and bounds.
They could at least direct you on how to at least start including some packaging into your LFS build.
You’d have to take that argument to the book authors. It does say it in the book, and does give some ideas about package management. The book is simply an educational tool for building a working system from source.
In the 9.1 book, this is in section 6.3.
In my system, I learned how to build RPMs. I agree that updating is a lot of work. Keep in mind, though, that you don’t really need to keep upgrading to the latest version of all your packages as soon as one comes out. I really only update something when some other program needs a newer version of a package, or if there is a vulnerability in one that needs to be fixed. My gitlab is linked in a post above. It has quite a few SPEC files. There is also a script called ‘repackage_lfs’ which packages up the base LFS packages into RPMs. Feel free to check it out to get some ideas.
Not really.
saying basically, “What it provides is a roundup of the more popular techniques and how they work.” is hardly a how-to.
I have given up on LFS for now and going to just try to learn how to fork another Distro.
Woohoo! LFS 10 is out as a release candidate. I’m looking to start a build in September when full release is out. That gives me a full 6-month window to finish this and BLFS before the next release! Anybody else interested?!
Update:
LFS 10.0 released yesterday. I want to start early this time to have a full window to work on BLFS which is a big part of my goal. Anyone else?
1 Like
Update on my LFS 10 build:
I’ve reached Section 9, so have done the vast majority of the build and now need to work on configuration files. Compared to version 9, the most significant difference (recalling from memory) is that there’s a lot more explanation of how the multiple phases fit together in terms of building and isolating the tools into their own environment which will eventually become independent of the host.
There was one stage at which I had a problem: straight after backing up (which I did, thankfully) after chroot, the new environment does not have the critical variable $LFS exported and may corrupt host files if this isn’t exported first, manually. I learned this after losing work and having to rollback(!) Just before configuration begins in Section 9, there are different commands for chroot, and $LFS again has to be exported manually, which doesn’t appear to be mentioned.
1 Like