Well, I guess this is my third post in this forum and this is going to be about LFS like the other 2. Fine, I have experience with Linux (used as my main desktop OS from 2011 to 2020 before I get a mac) and then recently, I got back to Linux somehow.

It's a long story which is irrelevant here, but I had to configure and create some systems based on Raspberry Pi and Orange Pi single board computers and you guessed it, You need Linux for those babies. I personally love to work with Linux machines, so I decided to do something myself.

I made LFS and ALFS systems before (if you look at my profile you'll realize I asked a question about ALFS in 2019) and it was an enjoyable procedure. However, I still have some big questions, since I have done a lot of stuff just for fun and learning and not as a very serious project.

• First I know BLFS exists, but I don't really know how to apply it to LFS/ALFS systems. I need some guidance for reading the book. So any tips, tricks and advice is appreciated.
• After that, I have questions about package management system. What package manager do you suggest the most? I personally tried some alternative package managers before such as pkgsrc and brew. But the distribution I made was based on Debian GNU/Linux and you can guess, I still had the power of apt in my possession.
• What about making ISO images? As I searched, LFS provides Live Scripts. Are they enough?

And I have to say that I asked pretty much the same thing on reddit as well and I didn't get the answer I needed. I hope I get here!

Thanks!

IME, LFS is not as well supported as it once was. The LFS book is up to date, but many other projects have lapsed. But it's one huge bash script that needs constant tweaking. ALFS I don't know the state of. For Macs, Asahi Linux is aimed at M1-M3 machines, and is the only distro I know of with Mac graphic drivers. I'm no great authority, I should add.

For SBCs like RazPi & Orange Pi: to get running you need

1. The usual Gnu & Linux packages compiled from source.
2. Arm-specific patches to prevent compile failures in what is basically x86 & x86_64 code.
3. Manufacturer-specific boot code and firmware. Every sbc seems to be unique in how they handle that.

I would feel it's unwise to reinvent the wheel, but use somebody else's work. If you go up market in your SBC to things like Solid Run http://www.solid-run.com they are probably "Arm Server Ready" with UEFI and all that. You can get Arm Server distros (RH, Fedora, SuSE, etc). With cheaper SBCs, booting without the correct kit is simply not going to happen.

Debian are paid (I imagine) to package an Arm distro for each SBC with the relevant boot setup. It can be downloaded as a binary image, and transferred to sdcard or usb drive with dd or their windows imager. Look on the manufacturer's site (e.g. raspberrypi.com). Slackware has Slackware Arm & slarm64, official & unofficial Arm ports respectively. I use Slarm64 on my RazPi 4, because the raspberrypi software sucks, & I prefer it to the 'official' port. Slackware Arm is too like the x86_64 original, and Aarch64 ≠ x86_64.

Well, my Mac is Intel based and I already managed to have major/famous distributions on that (since you've mentioned Asahi here, I just wanted to point it out) and my question was basically about the whole LFS ecosystem. By the way thanks for the useful information you've provided to me, it shines light on my path obviously.
This is more of a personal opinion than a fact. I guess LFS approach for SBCs isn't really a good one since most of them may have an industrial (or at least semi-industrial) application. In my case with those, I used them for a lot of automation and stuff and I used Debian for them. Recently, one of my Raspberry Pi boards (which is somehow a make-shift PC for me) runs Arch Linux, and that's cool for a very minimal desktop computer in my honest opinion.
So, I believe I can still take the LFS approach for x86_64 and get results out of that. What do you think?

LFS is a good thing to build once, but I wouldn't try living there again. I did once. It's a time hog. There's no way to install dependencies, so you often have to endlessly play 'whack-a-mole' with dependencies. Then there's no way to uninstall something efficiently, so you end up with misleading .pc files and unwanted dependencies & bloat. You want to use the computer mainly, not build the OS mainly.

LFS runs fine on SBO's.
From RPi1->RPi4, also a couple of RockPi SBO's.
All run fine with wirless and graphics ( when needed, I usually run them headless ).
Used for media servers, including books, comics. music, films etc.
Also used to use an RPi as an appache server.

1 members found this post helpful.

You know, I just was curious about the way independent distros are made. I have some ideas in mind which are closer to the ways Sabayon or PCLOS are made. I may share some information on the topic as soon as possible.

There is no reason it doesn't run fine, since it is Linux and Linux proven to be great at running on different hardware.

I'm not sure I've understood the question, but anyways... I've made my own distro, based on LFS, and kept it updated for 11 years. I don't use ALFS, I've made my own scripts which just automate the build process, following the book. I install a package manager, pacman and it's dependencies, in the tool chain. And in the chroot I create packages and install in the chroot. And I continue building everything in the chroot. When I update I do fullsystem backup to a different partition and just update with the new packages. If it doesn't work I can just reboot back to the old system. I look a lot at Arch and their PKBUILDs, but most often I follow (B)LFS. When I update different packages I usually compile them in a chroot. Especially the core packages, so I can test them in the chroot before installing them on the running system. So I guess one can say that my distro is some kind of hybrid between source based and binary distro.

1 members found this post helpful.

That is amazing!
One question, can I know the name of your distribution?

I haven't released it. I don't know if it is right to call it distribution when I haven't distributed it, but I diviate so much from LFS that I can't really say I'm running LFS.

When doing a BLFS, you need to follow the dependencies quoted for each package including the "recommended" ones. In theory these are optional if you use the right compile flags but I've never got that to work. Packages that are already in LFS are not included among the dependencies because you are assumed to have them.

Well, it's basically a distribution, but distributed to you only. I guess it still is amazing!

I encountered the same problem even on Debian with its proper package management system while using --no-install-recommends flag (I don't remember the flag correctly). And you know, it's not surprising that it becomes a serious case in the setup where you basically compile every single part of the OS from scratch.

You're not the only variation on LFS. http://kevux.org is another. The guy is fed up with glibc, and was using µClibc when I built it 20 years ago. No locales in ÚClibc. I haven't tried it.

As the Arm guys also showed (or found out) there's a big difference between a bunch of gnu programs compiled, and an OS. Design decisions have to be made. Most put 64bit libraries in /lib & /usr/lib, and 32bit ones in /lib/32 or /usr/lib/32 or the like. Slackware uses /lib(=32bit) & /lib64(guess!), which imho is superior. But much time is lost with things like udev, or maybe eudev, dbus, init systems, packaging, dependency tracking. In the case of LFS, I disagree with several of their choices. But in varying it, you're 'cruising for a bruising' unless you're smart. and 11 years down the road, I guess you know what you're doing.

I would call your distro a fork of LFS. lfs-hag?

if you’re feeling adventurous check out sourcemage. i’ve converted jhalfs scripts into a sourcemage grimoire and used sorcery to build the packages. then convert the packages to slackware using makepkg and use slackware pkgtools as your package manager

also i would highly suggest not building blfs by hand, or even building lfs by hand more than a couple times. learn how to use jhalfs.