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 
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 
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="... $(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

I don't mean to be a debbie-downer here, but I feel like if this is
desirable to you then what you're looking for is Gentoo. I'm NACK on
this feature for Alpine/apk.

I think maybe a compromise could be APKBUILDs which have build-time
configurability, kind of like what we already have for packages which
can be bootstrapped (e.g. gcc). But I don't think that would find its
way into the binary repos or ever be a mainstream feature, and I'm
generally against it becoming a widespread habit in aports.

On Mon, 2019-12-02 at 16:03 -0500, Drew DeVault wrote:
> I don't mean to be a debbie-downer here, but I feel like if this is
> desirable to you then what you're looking for is Gentoo. I'm NACK on
> this feature for Alpine/apk.

The objective of the RFC isn't to turn Alpine into something like
Gentoo or Exherbo though - I don't want to propose adding variants to
every other package, but for the few ones where it really does matter
because we can't split functionality out, like with FF and Polkit and
then only for one/two variants. I don't doubt that having this would
lead to having more packages with variants (e.g. I'd like to have
NetworkManager with elogind support, but I'm sure lots want it without
elogind support).

> I think maybe a compromise could be APKBUILDs which have build-time
> configurability, kind of like what we already have for packages which
> can be bootstrapped (e.g. gcc).

Yes, the problem is that once we have build-time configurability we'd
either need apk to interface with abuild (to automatically rebuild the
package in your configuration on updates instead of downloading the
version from the binary repos, which IMHO is much more gentoo-y.), or
just have apk install the upstream version (which might break things if
you rely on a certain feature set) or pin the version (which might
cause you to be on an unsupported release).

> But I don't think that would find its
> way into the binary repos or ever be a mainstream feature,

Yes, having buildtime configurability seems a bit clunky and usually
isn't really used (see Void Linux' "vopts").

>  and I'm
> generally against it becoming a widespread habit in aports.

Yup, we shouldn't overuse it, but some configurability in the packages
would certainly easen accomendating for a broader range of systems.