This post is entirely written by hand, in vim, by me, Jeremy Huntwork, the creator and maintainer of Mere Linux. The three previous blog articles on this site were shaped and guided by me, but composed by AI. Similarly, the package manager for Mere Linux, mere, was very strongly shaped and guided by me, but written by AI. I have no problems stating this openly and clearly. And now that I have a clearer picture of what was produced and what is possible I can say two things: ...
The package manager works. The recipe format works. CI builds packages for both x86_64 and aarch64 and publishes them automatically. What’s missing is packages — enough of them to make a system you can actually use. That’s where the road heads next. We’ve sketched out three broad milestones that lay the course for which packages will be added and in roughly what order. Three milestones 1. Bootable networked system Goal: Mere boots on real hardware or a VM, initializes services with s6, connects to the network, and builds its own packages. ...
Every package manager I’ve used draws a line between what you ask for and what you get. npm has package.json and package-lock.json. Cargo has Cargo.toml and Cargo.lock. Nix has flake.nix and flake.lock. The pattern is universal: one file for intent, another for resolution. You write the first. The tool writes the second. They’re different formats with different rules, and you need both to reproduce a build. This split exists for good reasons. Intent is loose — “give me vim” — and resolution is precise — “give me vim 9.1.0, release 1, with this exact content hash.” Those feel like different things, so they get different files. ...
Mere Linux has been quiet for a few years. That wasn’t accidental. It started with dissatisfaction with pacman. pacman is a great package manager, and it serves the Arch Linux community very well. But three things kept gnawing at me: A build system based on Bash. The scripts that drive packaging can be slow, fragile, and difficult to extend with code that is testable and portable. True build isolation required external tools. I had already patched makepkg to avoid the problematic fakeroot utility and instead used Docker containers. This worked well, but it still required a fair amount of glue. Officially, package signing requires a GPG setup. I have never been a fan of GPG and wanted to use something lighter and more modern. I had actually patched pacman to use asignify, but that patch was rejected upstream, and reasonably so. It also wasn’t a direction I felt fully aligned with. So I paused. ...