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.