This all started with ArchLinux ARM breaking the desktop experience on my ASUS C201 laptop, because I happened to try to update while they were in the middle of building KDE 6. That caused me to look for alternatives that would not give me partial, untested, updates. So, a moment later I was running Debian. *shudders*.
To be honest, that incident was just the "final straw" of living with Arch-ARM. There were other troubles beforehand (and inexplicable crashes with some apps, etc.)
Anyways, a moment later I was building big parts of QT/KDE 5 again because Debian thought ARMv7 is a "GLES architecture" and didn't include GL support somewhere in Qt (i think) I don't recall exactly what bit it was that was wrong, but yeah it prevented OpenSCAD from being built. Also, debian shipped an ancient version of KiCAD (and no FreeCAD).
My rebuilt-qt-debian-kde5 was functional but had some inexplicable graphical glitches. And I didn't want to do the "rebuild my stuff when the OS vendor decides it's time to update" again.
So, I decided to become the "OS vendor", and show that a proper KDE 5 desktop, with a rich set of applications can run on the ASUS C201.
I started off with LFS 12.1-systemd with some personal changes (using GCC 12.3.0 and Python 3.11.9), but since i knew I'd need a package manager, i picked the one I was familiar with and installed pacman (and it's dependencies) at the end of LFS ch 7.
The host system for my LFS journey was a debian armhf container running on an aarch64 Arch-ARM "host" (which is a VM running on an Oracle-provided Ampere Altra VPS).
I went through LFS chapter 8 in a roundabout way by writing a very barebones PKGBUILD for each package (based on the LFS scripts).
This set of packages became what is the ARMLFS "core" set. This is also what made the system have a seperate /usr/sbin (from /usr/bin) directory, and /usr/libexec. I'm not sure if I'd do the same if I was building it again, but in principle i like /usr/sbin. (Libexec I'm more "meh, whatever" on.)
Oh yeah, when i was starting the project, i needed to name the directory. I didn't want to stop the project to spend time on a good, fancy, name. So "ARMLFS" ("I'm following the LFS guide on ARM, duh") it was.
But going past LFS chapter 8, i started using more and more of PKGBUILDs just "loaned" from Arch Linux (or Arch ARM), since they were available and already in the correct format for my package manager.
But unlike Arch, i've been keeping a careful log of the order i've built the packages in - and of the solutions needed to break any dependency loops.
This is where I could go on a rant about dependency loops, but i'll try to keep it short and just say that the linux ecosystem has way too many, and I hate them.
Anyways, at this point I also moved the system from a chroot on the debian system to a direct container "child" of Aarch64 Arch-ARM host.
The packages beyond LFS (and yes, with some help from BLFS 12.1-systemd) are in the package repo named "base".
For packages in "base" onwards I use a "clean chroot" way of building, by using systemd-nspawn to spawn a volatile container (with a copy of armlfs core package set) for each build - my edits to the PKGBUILDs might cause some automagical dependencies if built outside this environment.
Oh yeah, I also build everything with the debug+strip options, that is I build a -debug package for everything, and I serve those debug packages with debuginfod to allow analysis of core files on the device.
This has taken months. I'll skip to the present.
builder # ls -1 /sources/pkg-* | grep ".tar.xz" | wc -l
2818
What. Oh yeah, there's duplicates of everything because of the "-debug" thing, and many PKGBUILDs build several packages (docs etc). Firefox-i18n has many packages, lol.
But still, by now I also have a "kde5" package repo - it has everything that depends on qt5-base. Maybe it should've been named "qt5". Oh well.
Anyways the point being the showcase desktop install is at over 700 packages, and has a rather nice set of available software:
- a KDE 5 desktop running on wayland
- Firefox
- LibreOffice
- Inkscape
- Krita
- KiCad
- OpenSCAD
- FreeCAD
- Kdenlive
Along with all the core tech enabling stuff, like Mesa (panfrost), Pulseaudio, Networkmanager, BlueZ (yes, bluetooth headsets will work), etc.
And now i've realized that to do what I really started off to do, to show Arch-ARM and Debian and every other distro out there that you can do a better experience (especially on armv7), i need to release this to the public, and that's why I'm writing this.
Thanks for reading so far, bye.