Mail archive

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

From: A. Wilcox <>
Date: Mon, 24 Jul 2017 10:20:17 -0500

Hash: SHA256

Hello there,

On 24/07/17 09:53, Shiz wrote:
> Hi,
> Thanks for sharing your experiences! I’ll comment on the specific
> cases below.
>> 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:
> I’m in general not a huge fan of how bootstrapping works at the
> moment, but I don’t see a direct way to improve it without
> rewriting it entirely and adding significant new functionality
> (like proper multiline) to APK.

APK already knows about architectures. And that won't really help the
fake cross: x86_64 == x86_64. Maybe a hack would be to do something
like replaces="gcc" in gcc-$arch packages? Theoretically they should
be in separate directories anyway, but I am not sure if that would be

>> 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.
> This is correct and something that has been bothering us for a
> while. A while back I wrote up a rough sketch of how such a system
> would function in APK, which is likely what you are referring to.
> It can be found here:

This seems like a decent start. I like how you can select all
provided paths from a package or just a subset. This was actually
requested by one of our early alpha testers.

Would the relocations database have *every* file, or only those in
conflict? I can see the argument either way.

> I have no specific experience with apk-tools’s internals, but
> would be open to looking into them to see what’s needed,
> possibly/preferably with kaniini and fabled’s assistance and
> insights as well.

I have some experience with the internals of apk-tools, but not so
much the database portion. Perhaps that is a task for this weekend :)

> Something I’d like to see is file: dependencies (in the same vein
> as so:, but for full file paths), but that’d require encoding the
> entire file listing of a package in its `provides` metadata, which
> I’m not sure we want due to APKINDEX file size bloat.

I know that both Debian and Red Hat based systems have something like
this stored in another index; `apt-file` and `yum provides`. The
databases are somewhere around 100 MB compressed, so they obviously
are not a part of the standard installation of apt/yum, but they are
available to enable at any time for the users. I'm not sure if Alpine
would want to do something similar. One method would be to have some
sort of 'simplification' step when generating APKINDEX: only include
file: from the master file database when a package references it. For


would cause every `awk` provider to have a provides: line in APKINDEX
for file:/usr/bin/awk. They wouldn't need to have a provides: for
every file, only the ones that other packages reference.

>> 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.
> I’m not sure what the best way to approach this would be in the
> system sketch I laid out above.

The above-linked specification doesn't resolve this in any way.
That's fine because it doesn't need to. That can be a separate
discussion / specification. (APK is already deficient in that regard,
so it should be fixed independently of adding an alternatives system,

>> 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.
> This would be a bug against aports in the bug tracker. Generally
> most of us are somewhat busy, especially considering the time of
> the year. Pinging specific people can work however — don’t take
> our lack of response as lack of interest. :)

I never took it as a lack of interest. I know that people are busy
and have jobs and families and lives; for most of us, Alpine and
related open-source projects are things we do because we like doing
them, as a hobby. I will go ahead and file the bug in that section
and keep that in mind if I come across any in the future.

>> 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?
> These kind of changes should be sent to alpine-devel if you do not
> wish to use GitHub.

Duly noted. I would ask if there are any plans to install something
like GitLab, Pagure, or Phabricator for Alpine at some point, but I
don't really want to open such a can of worms :)

>> 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.
> I’d like to see this, yes. It seems like a good addition in light
> of the things discussed at FOSDEM with regards to init systems.

I will send the patch to this list later today. It is very similar to
the doc split function, so hopefully it is acceptable. If it is
accepted, I will gladly forward on the packages that I have already
split out -openrc for Adélie.

>> 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.
> I’m not personally interested in bsdtar as I consider libarchive
> fairly bloated, but if the patch is backwards-compatible with GNU
> tar I would see no issue with including it at all.

The patch is not for abuild. It is for libarchive itself. Renaming
bsdtar to tar is sufficient for abuild to use it.

> Hope this helped a bit, - Shiz

It did indeed. Thank you very much!

All the best,
- --arw

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


Received on Mon Jul 24 2017 - 10:20:17 UTC