Date: Mon, 02 Dec 2019 15:09:29 +0000
To: ~alpine/devel@lists.alpinelinux.org
From: Rasmus Thomsen <oss@cogitri.dev>
Reply-To: Rasmus Thomsen <oss@cogitri.dev>
Subject: [RFC] Package variants (options) in apk
Message-ID: <aa66ed8e48403563b5bdcf9f87da924eae654559.camel@cogitri.dev>
Feedback-ID: LZW2MXNaH7NSG88i8lGpebeqB0wmcl0-3TbzkSuzsmAwEQspn4GI-WRe8j3PhRL4SBmua4rQWq6fadPcLS5uxQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello list,

I'd like to propose adding variants to apk, see further detail in the
RFC I've attached below (I guess I should make a gitlab issue for that
(?))

## Objective

It's hard unifying the diverse desires/requirements of users with one
package, as such we have some packages twice in the aports tree, both
built from the same source but with different configurations, e.g.
"polkit" and "polkit-elogind". I propose instead of having two
different packages built from different APKBUILDs (each having to be
maintained separately) having one APKBUILD that builds two "variants"
(or flavours or however you want to call it)

## Motivation

Different users have different priorities: Some want completely minimal
packages, others want at least a baseline of features. This RFC
actually was spawned by=20
https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1051. Some
users want Pulseaudio to be enabled in FF, others strongly oppose it.
It'd be nice if we could satisfy both.

Having variants has multiple advantages:
* It's less maintenance effort. Instead of having to care about two
APKBUILDs which only differ in one/a few configure
options/dependencies=20
one only has one APKBUILD which can build two packages.
* It's cleaner: E.g. the polkit & polkit-elogind can be a bit messy
since you need replaces&provides for it to work. Right now you
can't install polkit-dev and polkit-elogind at the same time.

## Design Proposal

Have an optional `build_options` (or similiar, `options` is already
taken) field in APKBUILDs where you can specify build options (e.g.
`pulseaudio`). Afterwards you can do `$(option pulseaudio <do-
action>`), e.g. `makedepends=3D"... $(option pulseaudio pulseaudio-dev)`
to only add pulseaudio to makedepends if the option is enabled, or
`$(option pulseaudio --enable-pulseaudio --disable-pulseaudio)` to
enable/disable pulseaudio in the ./configure if the option is
enabled/disabled.

There are multiple ways to tackle the apk side of things:

A) Have an abuild-only implementation:

Abuild could automatically generate a `$pkgname-$optionname` (e.g.
firefox-pulseaudio) package from this (I suppose it'd need firefox-
pulseaudio-$subpackages[@] too) and add the `provides`/`replaces` for
this. This does introduce some magic, but IMHO this is worth it since
doing this manually each time is tedious and error prone.

B) Have integration with apk too.

Instead of exposing the fact that abuild generates multiple versions
of  the package to the user via package names we could have some
special syntax for it, e.g. `firefox[pulseaudio]` instead of `firefox-
pulseaudio` and have apk handle the `provides`/`replaces`.

### Alternatives Considered
We could keep going like we currently do and only expose a minimal
variation of packages, but IMHO this usually leads to some party being
unhappy with the direction a package is going (too feature packaged and
bloated vs. too minimal etc.). This also needs less mirror space, but
IMHO we shouldn't use the variants too often either (only in cases
where we can't optionalise the dependency, e.g. in firefox vs firefox-
pulseaudio, polkit vs polkit-elogind etc.), so I expect the impact to
be negligible.


Regards,

Rasmus