Expression of interest and support #66

Apologies if this is the wrong place, but I wanted to note my interest in this project. A number of things co-incide with my interests and recent work: lightweight, musl-based Linux; Zig; Nix but with filesystem standards; and KDL.

Elsewhere, I've discussed the idea of blending Alpine and Nix before, but the broken filesystem standards are often the main limitation so we generally stick with Alpine or Arch. I've thought about sketching a Nix-but-not-Nix declarative package manager for a while, but not got very far. It looks like Mere Linux could be a good fit, and I'd like to give it a try.

I know very little about systems programming and my studies take up 110% of my time, but I'd be keen to experiment. For whole systems, I've recently been fiddling with Alpine Linux container images and have a spare uSD card to image for a Pi; otherwise, I could test Mere on top of a fresh Alpine system or in a Podman image.

Please let me know if there's a way I can contribute!

Hi! Thanks for the kind words and interest!

I think there will likely be lots of ways to support and help in the very near future. I'll need testers and help producing recipes, documentation and keeping existing recipes up to date. What's missing right now is the documentation that shows how to do any of that. I will try to get some of that in place soon and hopefully that will give people guidance on how to jump in.

Stay tuned, please!

No worries, and apologies for my delay in responding!

I'd like to try my hand at writing recipes for sure, it's similar to what I've been doing with Containerfiles/Dockerfiles for reproducible research. Most of the time, research software is not packaged, so my work there has been of more interest than I thought. My thought is how to install a recipe from a local file rather than from a recognised remote repo, but maybe recipe dev should have a central remote anyway.

I tried building Mere from source on a fairly blank (and GUI-less) RPi 4, just from the current head. I fixed a couple of build failures but one is a sticking point. If I have things like that to document, is there a better channel to do so, or should I keep adding to this or another thread?

In any case, I will keep testing and making some notes, and thank you again!

Here is fine for now for anything you find. Pull requests and other issues for specific bugs are good too.

I'll send an update here when I have a doc created that walks you through a local dev flow.

And yea, you should be able to build, install and use your own local packages. 'mere --help' should guide you through that, but if not, the dev doc I hope to produce will soon.

No worries. The two main things I've found are dependencies in Alpine Linux and an unknown symbol (std.process.Init), but the latter was simply because the Zig version in the apk repos is currently out of date (v0.15.0 rather than v0.16.0) and I didn't think to check before trying to build.

For the former, I found I needed a handful more things than musl, LLVM, busybox, curl, and cmake, but I was running a Podman build starting from Alpine v3.23. I also needed build-base, linux-headers, make, and mbedtls. Below is the minimal working containerfile/dockerfile; running podman run ${IMAGE} sh -c 'type -q mere' correctly shows /usr/bin/mere.

Note that my methods might be a bit unconventional! I'm open to learning new and better ways.

FROMalpine:3.23ARG ZIG_VERSION=0.16.0RUN <<EOF	apk update	apk upgrade	apk add \
		bash \
		build-base \
		cmake \
		curl \
		git \
		linux-headers \
		make \
		mbedtls \
		wget	apk cache clean	apk cache purgeEOFRUN <<EOF	ZIG_DL_FILE="zig-$(uname -mo | tr ' ' - | awk '{print tolower(0ドル)}')-${ZIG_VERSION}.tar.xz"	ZIG_DL_URL="https://ziglang.org/download/${ZIG_VERSION}/${ZIG_DL_FILE}"	ZIG_DIR="/etc/zig-${ZIG_VERSION}"	ZIG_FILE="${ZIG_DIR}.tar.xz"	wget -q -O "${ZIG_FILE}" "${ZIG_DL_URL}"	tar -xf "${ZIG_FILE}"	mv "${ZIG_DL_FILE/\.tar\.xz/}" "${ZIG_DIR}"	unlink "${ZIG_FILE}"	ln -s "${ZIG_DIR}/zig" /usr/bin/EOFRUN <<EOF	mkdir /proto	git clone https://codeberg.org/merelinux/mere.git /proto/mere	cd /proto/mere	zig build \
		install \
		--prefix /usr \
		--release=fast	cd -	rm -r /protoEOF

Hey,
I second this interest! I, like others stumbled on Mere in search for a modern package manager for musl+llvm based systems. The architecture is very interesting and seems very easy to implement on pretty much any system which would make it a great fit for small hobby distros, LFS-based installs or as a secondary packagemanager. Especially with the support of multiple init systems (merelinux/recipes#103) and unprivileged user installs (#67).

I'd love to see Mere be a packagemanager for multiple distros that can each rely on a shared package repository, with mere getting more contributors in turn, rather then having even more outdated PMs and insufficiently maintained and unpopulated package repositories.

@oryktos wrote in #66 (comment):

No worries. The two main things I've found are dependencies in Alpine Linux and an unknown symbol (std.process.Init), but the latter was simply because the Zig version in the apk repos is currently out of date (v0.15.0 rather than v0.16.0) and I didn't think to check before trying to build.

For the former, I found I needed a handful more things than musl, LLVM, busybox, curl, and cmake, but I was running a Podman build starting from Alpine v3.23. I also needed build-base, linux-headers, make, and mbedtls. Below is the minimal working containerfile/dockerfile; running podman run ${IMAGE} sh -c 'type -q mere' correctly shows /usr/bin/mere.

Note that my methods might be a bit unconventional! I'm open to learning new and better ways.
Containerfile for testing Mere build

Nice job! The mbedtls source should have been pulled down as part of the build... that part is a little curious.

@meelix wrote in #66 (comment):

Hey, I second this interest! I, like others stumbled on Mere in search for a modern package manager for musl+llvm based systems. The architecture is very interesting and seems very easy to implement on pretty much any system which would make it a great fit for small hobby distros, LFS-based installs or as a secondary packagemanager. Especially with the support of multiple init systems (merelinux/recipes#103) and unprivileged user installs (#67).

I'd love to see Mere be a packagemanager for multiple distros that can each rely on a shared package repository, with mere getting more contributors in turn, rather then having even more outdated PMs and insufficiently maintained and unpopulated package repositories.

Awesome, thanks for expressing the interest. That definitely aligns with how I've been thinking about it. I just need to find a little free-time to push through on some of the recently identified work. And one of the main next things is making it easier for people to help.

@jhuntwork wrote in #66 (comment):

Nice job! The mbedtls source should have been pulled down as part of the build... that part is a little curious.

I see! I tested it again to get the exact error if building without mbedtls and it worked fine -- false alarm, my apologies! I suspect I got my wires crossed, and it was probably caused by the Zig version mismatch.

I get one desktop notification every time I build, but no evidence in stdout/stderr:

Service Crash: /tmp/tmp.XXXXXXX/build/conftest has encountered a fatal error and was closed

It doesn't stop a successful build, but there's a down-stream failure I cannot resolve which could be related. I'll open a new ticket for that one.

(And good to see there seems to be a bit of growing interest in the project!)

Added this, hopefully it's helpful: https://codeberg.org/merelinux/recipes/src/branch/main/CONTRIBUTING.md

Please try it and let me know if there are any issues.