jhuntwork/merelinux

A lightweight Linux distribution using musl libc, pacman and s6

merelinux's Issues

Create a wiki

It is great moment to create wiki to put there documentation like this, either here on GitHub or standalone on merelinux.org

Originally posted by @lufv in #362 (comment)

--

It would be very helpful to have others contributing to documentation, a wiki of some kind should make this easier.

I really like musl's wiki. It is backed by a git repo where people make pull requests and is just simple Markdown that is then published as static html.

Add installation instructions

Eventually, user-friendly installation software may be nice to have, but in the meantime at least document the steps required to install the system.

There are at least three possible paths:

1. From a bootable Mere iso image
2. From a generic 3rd-party Linux system
3. From a raw disk image

Consider switching to OpenSSL from LibreSSL

There's been a lot of discussion around this in the wider Linux community. Several distros that were using LibreSSL have switched back to OpenSSL for a couple of reasons:

1. The issues that caused LibreSSL to fork back around 2014 have largely been addressed
2. Ongoing maintainability and compatibility issues with LibreSSL

A sample article that captures more of the motivations: https://lwn.net/Articles/841664/

It's worth investigation.

Upgrade to Python 3

It's probably better to choose Python 3 'from the beginning'. There's no major reason inherent to this OS or its design principles to stick with Python 2 and Python 3 is where the community as a whole is heading (and should be).

Separating packages from kernels, etc.

Hi! Sorry for not following the template but this is kind of different suggestion.

I've been wondering if now it's good time to create GitHub structure that would be used in the future. Right now everything in one place seems to work well but with time it might be harder to tidy it up into respective repositories. Maybe it's even good idea to create merelinux organization on GitHub if it doesn't come with additional costs. I'm not sure about it though.

Document merelinux usage of s6

• Design patterns and choices
• How to implement a new service using s6
• How to implement adequate logging (instead of using syslog). Additionally, some type of reference implementation for collecting and shipping logs over the network would be useful.

arm support, possibly aarch64 and armv7

I have some Raspberry Pis that should be running Mere :)

This is a longer term goal, will get to it when there is time.

git does not include the Perl git module

Describe the bug
The git package does not include the Git.pm perl module, so certain git commands fail.

To Reproduce

$ git add -p
Can't locate Git.pm in @INC (you may need to install the Git module) (@INC contains: /usr/share/perl5 /usr/lib/perl5/site_perl/5.32.1/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.32.1 /usr/lib/perl5/vendor_perl/5.32.1/x86_64-linux /usr/lib/perl5/vendor_perl/5.32.1 /usr/lib/perl5/5.32.1/x86_64-linux /usr/lib/perl5/5.32.1) at /usr/lib/git-core/git-add--interactive line 8.
BEGIN failed--compilation aborted at /usr/lib/git-core/git-add--interactive line 8

Questions about usability

It's not really a feature req but I'm wondering if

1. a web browser is available in the repos, from a rapid look i could not find any;
2. there is a chance to use a graphical interface with a WM like Openbox.
   Thanks and keep it up!

python-dev conflicts with python

Describe the bug
Both the python and python-dev package include the file /usr/include/python3.9/pyconfig.h file, so python-dev will refuse to install unless the file from the python package is removed first.

To Reproduce
Steps to reproduce the behavior:
Install python=3.9.2-3, then try to install python-dev=3.9.2-3

Determine a core and core-dev group as foundational packages

These two groups will be essential packages for building, installing and running a minimal Mere system. There is already the build-essential meta package, but I think core-dev might include some other non-essential ones like autotools, possibly perl and python.

This will drive finishing up what should mark the first pass of reviewing the current stable repo.

Some sort of alternatives support

Is your feature request related to a problem? Please describe.
There should be a way to support multiple packages that provide the same file or feature. For example, busybox ships with ps utilities that may be fine for some (most?) use cases. But someone may actually want the extended features that come with procps-ng. A similar thing is true for ip tools. The ones in busybox work great for most use cases, but if you want to set up a Wireguard connection, you will probably need some extended features found in iproute2.

Describe the solution you'd like
One possible way to solve this would be to install packages to a package-namespace location, like /mere/[pkgname]. Then, to use it, you either manage your PATH, or have an activate command or trigger that installs symlinks to typical systems locations in the standard PATH. A nice side-benefit of that is that you could install mere packages on a non-mere host and not worry about polluting or interfering with the host system, everything would live in /mere.

A more advanced implementation might be more like what Gobolinux or NixOS do, having version specific paths. There's a lot of potential with that, but also some unique challenges, especially when building, and much more impactful in the way the system runs. Perhaps something to consider with the package manager issue (#381), much further down the line.

Formalize a release strategy

There is no formalized release strategy yet, though there is a basic concept in place. Having a documented release strategy will help set user and developer expectations, and should lead to improved quality.

Right now, the automatic build workflow will create packages on pull requests and publish them to the testing repo after the pull request is merged. This is working well enough for the moment, but there are at least two questions still:

• Does the testing repo need to be even more stable than this? Arch, for example, seems to publish things first to staging where it is expected that breakage can happen at any point.
• What is the time/process for promoting things from testing to core (or other production-ready repos)?

Cron service

Provide the scripts and possibly configuration files for enabling/running crond

Support digital signing and verification of packages

The initial libraries to support digital signing are present, but they are not implemented into the build system nor are any packages actually signed yet. Further investigation and testing needs to be done.

Before promoting testing, practice upgrading a current stable system using testing

Document development environment and workflow

Related to #166

Add zig package

I have a working local version of 0.10, but 0.11 doesn't currently build on mere due to /usr/bin/env being a static binary (symlink to busybox which is static).

Related to ziglang/zig#14577

Investigate and choose some sort of mailing list

Kind of essential for communications of anyone interested in contributing.

Add Redis Support for PHP

pacman repositories

https://github.com/jhuntwork/merelinux/blob/master/packages/pacman/pacman.conf

Is it too early to redifine the two repositories we know about?
The db file for both (stable and testing) is main, so both can't coexist as two separate repositories.
Whether sticking to the name stable or following arch's core/extra/community or Obarun's example of obcore/obextra/obcommunity to separate from arch's, mercore/merextra/mercommunity :)

At this stage it is hard to go back and forth since what is in stable may not exist in testing, but what is in testing may be up a version or extra... like linux and linux-headers.

About a base metapkg
I'd like to see net-tools instead of the "modern" IBMish way but that is just me :)

Aslong as I don't see elogind and zstd here I am with you 100%

I am trying to make enough of a base here to start building myself and testing things. It seemed impossible in the previous stage, I wonder what was your base for building the first few pkgs, alpine, adelie, void-musl??

You have my appreciation ....

Detect version mismatch on provides

Describe the bug
A package may use the 'provides' keyword, but the packaging process doesn't actually confirm that it really does. It should be possible to detect this at build-time to avoid missing configurations.

CI/CD improvements

The development and CI/CD workflow is a little janky at the moment. There's a couple of issues:

• Larger packages that take a longer time to build (e.g., LLVM, Rust, Firefox) will time out in the current free tier of CircleCi.
• Each commit is expected to build one package. This isn't always desirable.
• Any solution for longer, automated builds will incur at least a momentary expense for launching cloud resources. This is fine, but then we probably want to protect against just any pull request from launching those.
• The flow or "rolling release" strategy between pacman repositories is currently stagnant as well.

I think all of the above makes it a prime time to also tie up loose ends in #377 #378 and #384. I'll let this be the driver for moving those things along, and I will probably begin making use of the https://github.com/merelinux organization.

I have also been toying with moving to Gitlab.com (while still mirroring here, probably). Anyone have any opinions on that?

Investigate nsss

https://skarnet.org/software/nsss/

Runs on bare metal?

Is it possible to run this on bare metal?
More specifically, a Thinkpad E495.

Thank god I found this... I was just going to make this EXACT SAME THING myself!
standards of musl + reliability of s6 + familiarity of pacman, a heavenly choice!

Add python-pip

This is a must have for any real Python usage.

Pacman should depend on ca-certs

Describe the bug
Pacman can read remote repositories served by https, but by default the CA certificate chain is not installed. Making the dependency explicit in the PKGBUILD will guarantee that this always works without a user having to manually install the ca-certs package.

Upgrade mongodb to 2.0.2

See: https://jira.mongodb.org/browse/SERVER/fixforversion/10991
See: http://www.mongodb.org/display/DOCS/2.0+Release+Notes

Finish developer documentation

Document how to set up a development environment as well as development principles to support additional contributors.

Determine initial config of kernel modules

The current kernel will already boot a large amount of systems, but it only has a few network drivers built in. Adding desktop support will also mean adding in drivers for video, sound, wireless, and others.

It might be nice to start small and add support in as requested/needed, but I also don't want to unnecessarily hamper new ones from being able to use the system.

Upload a sample raw disk image

Create a very basic, but working raw disk image which interested parties can use for testing, experimenting, setting up a development environment, etc. Should probably have both a raw disk image and a Virtualbox VDI formatted disk.

Boot manager/loader

Up to now, mere has used syslinux which worked great. I chose that because it was simple, relatively straightforward, while still supporting a lot of options and configurations.

But syslinux seems to be no longer maintained, the last release was in 2014. That alone might be fine if the software just works, but it also seems its compilation has some pretty tight dependencies on gcc, which we dropped in favor of llvm/clang.

So there's a few choices here:

1. Punt this decision and use the previously compiled version of syslinux already in the repo, not worrying for now about re-compiling it. Re-visit this issue at a later date.

2. Add gcc back to the repo to stand alongside llvm as an optional compiler to support syslinux and any other programs like it with a gcc dependency.

3. Choose and add a new boot loader/manager, probably either grub2 or refind

PHPs with-mysql-sock setting mismatched with mysql.sock location

On testing branch the with-mysql-sock configuration setting is pointing to /var/run/mysql/mysql.sock. However, mysql is building with mysql.sock pointing to the new and improved /srv/mysql/mysql.sock

Here is the PHP Configure Command:

System => Linux lightcubevm.lightcube.us 2.6.39.3-3 #1 SMP Tue Aug 30 07:47:06 UTC 2011 x86_64
Build Date => Oct 18 2011 17:05:28
Configure Command =>  './configure'  '--prefix=/usr' '--libdir=/usr/lib64' '--sysconfdir=/etc' '--localstatedir=/var' '--with-config-file-path=/etc' '--mandir=/usr/share/man' '--with-libdir=lib64' '--enable-sockets' '--enable-calendar' '--enable-bcmath' '--with-openssl' '--with-zlib' '--with-bz2' '--with-db4' '--with-curl' '--enable-pcntl' '--enable-mbstring' '--with-gettext' '--with-pcre-regex=/usr' '--with-libxml-dir=/usr' '--with-jpeg-dir=/usr' '--enable-sqlite-utf8' '--with-gdbm' '--enable-soap' '--enable-ftp' '--with-gd' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-mysql-sock=/var/run/mysql/mysql.sock' '--enable-embed'

Package Manager

This is a long term feature request

pacman works great, is lightweight, and has a lot of really nice features. It's served this project well, really helping it to focus on some of the more important things first.

But there are a few things about it I'm not so fond of:

Its heavy reliance on bash scripts for building

The PKGBUILD format is actually really nice and easy to understand as a set of build instructions. It's basically just bash variables, arrays and functions. And so it makes sense that the tool that uses it, drives the building, would also understand bash. However, as much I like writing shell scripts for their immediacy and appearance of portability, they are fragile. I generally agree with the sentiments in Rich’s sh (POSIX shell) tricks, notably:

I ... consider programming sh for any purpose other than as a super-portable, lowest-common-denominator platform for build or bootstrap scripts and the like, as an extremely misguided endeavor

The makepkg tool itself and all of its libs make up a full suite of bash that would be nice to replace with code that doesn't suffer from the same issues, something that can be truly unit tested, for example.

Its strong dependency on gpg for package and repository signing

Surprisingly, it looks like pacman (or maybe it's gpgme) shells out to to the gpg binary to do validation of packages. If only the gpg binary is removed from the system, pacman cannot validate signed packages.

Originally posted by @jhuntwork in #7 (comment)

I believe a package manager should be able to directly support digital signatures and verification without requiring the entire heavy gpg implementation on a running system. As of now, gpg appears to be the only signing tool that is supported by pacman.

Its user interface

I've used pacman for a while now, and so have started to get used to its short flags for nearly everything. However, even today there will be a specific feature I'm looking for and have trouble finding it. For example, looking up information on what packages are available to install, seems like it should be under -Q, --query, but that only works on things in the local system. To understand what the remote offers, you have to do -S, --sync. Also, if you want to know what package owns a file installed on the local file system, you can run pacman -Qo [file], but if you want to know what package provides a file or lib (local or remote) you have to do pacman -F [file]. There is a sort of sense there, once you are used to it, but I believe it isn't easy for new users to navigate the CLI options to find the action they are looking for.

I'm not decided yet on what direction should be taken, but my thought is to start by replacing makepkg, having it produce pacman compatible packages, and work from there in a sort of strangler pattern until pacman is fully replaced.

Again, this is a long-term feature request. Nothing with pacman is changing for the moment. Input, suggestions, ideas here very welcome.

Add mdevd

To begin using modules we need something to trigger modprobe automatically based on kernel events. s6 provides an implementation of mdevd that should work well.