Mail archive

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

From: William Pitcock <>
Date: Tue, 25 Jul 2017 00:17:15 -0500


On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox <> wrote:
>>> 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.

APK already stores all files available to it in the installed-db.
Thusly, we would only need to store the redirections.
I think this should be a component of apk-tools.

>> 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
> example:
> depends="file:/usr/bin/awk"
> 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.

This would severely bloat the APKINDEX. We should probably not do this.

>>> 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,
> IMO.)

This could probably be solved by 'preference levels'.
The package with the highest preference level and lowest depgraph
solution cost would be selected.

>>> 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.

Once sent over, I see no reason why it wouldn't be accepted.

>>> 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.

Lets go ahead and integrate this patch, I suppose.


Received on Tue Jul 25 2017 - 00:17:15 GMT