At the heart of Archlinux is the Arch Linux Package Manager (ALPM, commonly known by its binary pacman) and the Arch Build System (ABS, based on BSD ports collections). It could easily be argued that package management is what has really lead to Arch’s popularity. It came to be in order to fill the niche role of a rolling-release binary distribution, but that really wouldn’t have been feasible without an clear and simple way to add or modify package files, build packages for distribution, install them and their dependencies, and make it all understandable, customizable and straightforward.

The dependency system especially allows us to create packages that don’t install anything themselves, but rather simply pull in any of these defined dependencies. These packages are called metapackages, and this is one of the most undervalued features of the build system. Once I had a basic understanding of writing packages, I realized quickly I could use metapackages to simplify my installs. Instead of pacstrapping a group of packages (and usually forgetting one or two), I could pacstrap a metapackage and get everything I need. I could even modify that list of dependencies in my metapackage, bump the version, rebuild it and run an update, and ALPM takes care of it all automatically.

But I’m moving on from metapackages now, and I’m working on a new idea as a proof-of-concept that involves not just using an empty metapackage to pull in dependencies, but to accomplish all the configuration and setup involved in an installation. Essentially, I want to create a system whereby I can boot the install ISO, partition my drives, mount them, and then by pacstrapping just 1 or 2 packages end up with a functioning system that requires no further configuration. In a way, I’m trying to see if I can treat Archlinux like NixOS. To really test the idea though, I’m going to attempt to create a suite of packages with interdepdencies such that multiple systems in a small home network can all be managed, namely two simple servers and a handful of workstations. The servers will consist of a small pseudo-gateway and a media/file server, while the workstations will consist of various configurations for specific hardware, like my desktop and all my laptops.

The usefulness of this concept is not great, I admit. As stated, I’m basically trying to develop a way to use Arch like NixOS, and I’m a big advocate of, “Use the right tool for the job.” If one wants the reproducibility of NixOS, I would argue they should use NixOS. Hence why this is a proof-of-concept; it’s practical usage is questionable. But I think it still bears exploring given how easily it would make things to reinstall systems as many people seem to do regularly. It’s not inconcievable that some day this concept could be used to provide ready-made configurations, where newer users just wanting to test Arch could pacstrap a single base KDE or Gnome or i3 or whatever package built via this method and have a completely working system to play with.

In the meantime though, I have a lot of legwork to do. Ideally, I’d like to include a fairly extensive set of tutorials, both written and possibly in video form, that cover the basics of the GNU coreutils, the concepts both common to all Linux distros and specific to Arch, shell scripting, etc. Not an Arch installation tutorial as I am vehemently opposed to them in principle (the number of out-of-date tutorials out there frustrating new users and making their experience a terrible one is staggering, and the authors seem to refuse to take them down for some reason – presumably because they’ve monetized them in many cases), but a tutorial on the tools and principles. In essence, a tutorial series that, once reviewed, would arm the viewer with the tools and knowledge to simply open the Arch Wiki and follow it, resulting in a customized and supported installation. And unless there’s some major change in how the GNU coreutils work or Arch changes drastically, that would remain true.

The roadmap, including an indication of what’s already done, can be found below. But be warned: this list is subject to change and as someone with a career and responsibilities I expect progress will be slow. The timeframe for completion won’t be days or weeks, and might even extend beyond the year mark. But I’m in no rush and I would rather produce good content than fast content.

I hope the series proves helpful to some, and I look forward to seeing if this proof-of-concept even works.

Aeryxium

Task List

Strikethrough indicates completed task

Blog Posts

• Introduction
• GNU coreutils
• Block devices
• Linux FHS
• git
• Explanation of the ABS
• Building and installing custom packages
• Writing packages
• Package install scripts
• Dealing with global configuration files
• Final proof-of-concept review

Shell Scripting

• Multi-post series TBD

Proof-of-concept Packages

• CPU microcode
• Hardware drivers (i.e. GPU)
• Base
• Development
• Server
  • Pseudo-gateway
  • Media/fileserver
• Workstation
  • Desktop
  • Laptop