Mail archive

[alpine-devel] Adélie on Alpine, two months later

From: A. Wilcox <>
Date: Mon, 24 Jul 2017 06:57:52 -0500

Hash: SHA256

Hi there Alpinists,

This is a sort of status update and wish list after near two months of
attempting to base Adélie on Alpine Linux.

1. scripts/ cannot "fake" cross. Since Adélie uses a
slightly different GCC configuration from Alpine, I attempted to run on x86_64, from my x86_64 system:

ERROR: unsatisfiable constraints:
    conflicts: gcc-x86_64-6.3.0-r4[]
    satisfies: world[gcc] g++-6.3.0-r4[gcc=6.3.0-r4]
gcc-gnat-6.3.0-r4[gcc=6.3.0-r4] build-base-0.5-r0[gcc]
    conflicts: gcc-6.3.0-r4[]
    satisfies: world[gcc-x86_64]

Since we have other CPU types that we wish to support, I went ahead
and simply bootstrapped PowerPC. This is therefore not a fatal error,
but one that has caused a lot of time to burn; a lot of packages are
just not ready for ppc and needed some fixing. Specifically, GCC and
OpenSSL needed to be made aware of the PowerPC architecture.

2. The virtual system is pathetic. One of the very core tenets of
Adélie is giving the user power through choice. That choice is almost
impossible to provide using the current abuild/apk framework. I keep
hearing of a Debian-style alternatives system, and supposedly it was
specified somewhere, but I cannot find the specification nor an
implementation. If I could read the specification I would be highly
motivated to write an implementation.

Red Hat has `alternatives`, Debian has `update-alternatives`, and
Gentoo has `eselect`. The Alpine system desperately needs something
like this and I would love to contribute to such.

Consider a few different use cases:

mta: any package that needs `sendmail` has to either hard-depend on
postfix, or disable mail services. This is unacceptable in my
opinion. Other distros let you select what package you want to
provide `sendmail`.

awk: mawk vs gawk vs busybox awk. All have benefits and drawbacks and
the user should be able to choose which provides /usr/bin/awk.

shell: /bin/sh as busybox is of course default, but some users may
want bash or another shell. I don't see any reason that can't be

vi: busybox, vim, neovim, elvis, ... There are almost a dozen
providers of `vi` in Debian and more than a dozen on Gentoo. I
believe Alpine itself packages four of them.

I started to try and make 'v:mta' but I'm very concerned about
diverging so much from the Alpine aports tree. Also, apk doesn't
support an automatic choice for a virtual if the user hasn't already
installed one (something like replaces_priority but for virtuals would
be good here imo). That means that when I *do* manage to get packages
to depend on v:mta, the user now has to read through an 'unsatisfiable
constraints' error and pick a package out of the list of providers.

3. It is very hard to know where to send some things. For example,
the GCC APKBUILD does not function properly right now: it does not
declare a makedepends on gcc-gnat, and the GCC configure process bails
out when it does not find it because LANG_ADA is true whenever CBUILD
== CHOST == CTARGET. I am not 100% confident in my ability to edit
the APKBUILD for GCC considering how finicky it is, so I would like
help. I posted on the IRC channel but I mainly only have the weekends
to work on Adélie, and most of the channel is away on weekends. This
really isn't a distro topic, so it doesn't belong on alpine-devel from
what I have been able to gather about this list. The aports list
seems to be for patches only, from what I have gathered about that
list. Maybe this belongs on the bug tracker, but there really isn't a
bug category for build failures that I could find.

Additionally, changes made to abuild or apk-tools are currently being
sent via GitHub pull requests. However, none of us in Adélie really
want to use GitHub as it is a closed platform. The aports mailing
list exists for aports, but where could we send abuild or apk-tools
changes if we wanted an alternative to GitHub?

4. We have managed to make a split function 'openrc' that takes
/etc/init.d and /etc/conf.d directories. It has install_if="$pkgname
openrc" so it is transparent when you have OpenRC installed, and
allows future migrations to a different init system. I don't know if
this is of any interest to Alpine.

5. After being annoyed by bugs in the PowerPC build of GNU tar, we
managed to swap out /usr/bin/tar for bsdtar provided by libarchive in
abuild. It needed a patch to output the format apk expects by
default, but otherwise it seems to work quite well. This may be of
interest to those who want to do a GNU-free Alpine spin.

- --arw

- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
Version: GnuPG v2


Received on Mon Jul 24 2017 - 06:57:52 UTC