Mere Linux is a lightweight Linux distribution built around
musl libc and
s6 for system initialization and process
supervision.
The goal is a minimal, understandable system where packages are immutable,
upgrades are atomic, and multiple versions coexist cleanly — using plain
directories, symlinks, and user namespaces rather than heavy abstractions.
Mere uses its own package manager
written in Zig, busybox for core utilities, and
llvm+clang as the toolchain.
New to Mere? Take the Tour of Mere to learn how the package manager
works.
Mere is under active development — the toolchain is solid but the package
manager is new, and we’re still growing the package repository, docs, and
tooling. Here be dragons. You can follow along and contribute at
codeberg.org/merelinux/recipes.
The Road Ahead
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. ...
One File
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. ...
A New Package Manager
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. ...