I am excited to announce a milestone in the Dark Horse Linux project.
The code in the repo has finished creating the initial target system, including the kernel compilation using the default Fedora Linux kernel config.
There is an exception, the fstab file, which has a chicken-egg problem to resolve but I consider this to be minor and can be resolved during the ISO file generation, which is the next piece.
I should be able to use grub-mkrescue or genisoimage/xorriso or some combination of these with a thought out init ram disk to complete that part.
Once complete, I’ll start polishing the codebase for Pyrois up, branding a fork of it for ALFS-NG, and tag and release that for now.
For the long term, the `ALFS-NG` spinoff is just a side project that got spawned by this effort. I haven’t decided if this is something I want to give to the LFS folks to revive/modernize their seemingly abandoned ALFS project, or if it should remain wholly separate due to the Darcy infection. I have a desire to “play well with others”, but, that can’t occur in a vacuum, and I need to be certain it stays shielded from Canonical based on previous behaviours.
On the other hand, it’s likely to go very stale if I keep it under my thumb as it’s not a priority for me to keep it up to date more than to facilitate it as an instructional device. I suppose that begs the consideration that they’ve already abandoned that project once, so, it may not be a priority for them either. They likely wouldn’t want it.
I will then want to decide whether I want to introduce librpm for the next phase, or whether I want to create an installer disk, presumably with something like `anaconda`, though, I am hesitant about introducing an upstream dependency on the RH ecosystem based on the goals of the DHLP project.
I will want this system to be very familiar to RH-based distro users for many reasons, but, all cooperation with external projects must be a voluntary effort that can be easily severed for this mission to work. This is, after all, a contagion firewall. I’m already going the librpm route, which is maintained by RH, but, many distros use librpm. Not many use anaconda, so, their maneuvreability is different with that piece. Not that I think anything would happen there, but, it’s a risk surface that needs gaurded.
I suppose I’ve answered my own question thinking it out — anaconda is a package-based distro installer, so, if I’m going the librpm route I need to do that first before anaconda.
I suppose one approach might be to build my own basic installer that is a modification of the sysroot I’ve created that just copies the unmodified sysroot to a target system after the user selects and mounts all their target mounts. That’s a thought. Copy it off, when it’s done in the build, then engage in a 6th stage that turns one of the copies into an installer that puts the intact copy onto the target system.
I may do that first to move forward on a known working path, and then do my reductionist cross-reference with other similar projects to synthesize a new process. It’s a bit of a longer path but it’s one that can provide consistent progress.
Of course, things are always subject to pivot based on what I learn as I go through this. I have no experience with this aspect of things, so, I’m certainly open to ideas.