Subject: APKBUILD Optional/Recommended Dependencies

From: Cosmo Borsky <[email-masked]>
Date: Mon, 12 Aug 2019 05:16:42 -0400

I've started to move over to Alpine for my systems, and noticed there's
nothing in the APKBUILD specification about listing optional dependencies.

https://wiki.alpinelinux.org/wiki/APKBUILD_Reference

I did a basic search through the mailing lists along with a grep on
aports, with no results.

Arch Linux's PKGBUILD has an `optdepends` flag that provides a way to
list packages that provide additional features to the software.

https://wiki.archlinux.org/index.php/PKGBUILD#optdepends

My initial thoughts would be to add in a variable such as
`depends_recommended` or `depends_optional` to allow package
creators/maintainers to list recommended packages.

`apk add --install-recommended pkg`

Has this been discussed before? Does anyone think this would be a useful
addition?
I'd be happy to work on a patch to abuild if it could be desired.

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 12 Aug 2019 10:06:18 +0000

Hello,

we've had a discussion about that on #alpine-devel some time ago. I'd also welcome adding optional dependencies, but I'm unsure how we'd want to design this, here are some of my ideas:

1.
Have "optional" deps, which are opt-out via a config switch in /etc/apk/* or via a CLI switch. There were some concerns that this would conflict with Alpine's goal of being minimal since optional deps might have some significant weight attached to them.

2.
Have "optional" deps, which have to be opted-into via a config switch in /etc/apk/* or via a CLI switch. This mitigates the previously mentioned problem of having big optional deps pulled in by default, but I personal doubt that many people would flip the switch to actually make this useful. Maybe a switch in the installer would be sufficient for this though.

3.
Have "optional" and "recommended" dependencies. Optional deps wouldn't be installed by default (and could be enabled as previously outlined, as opt-in), whereas recommended ones would be opt-out (also via a config/CLI switch). We'd need some guidelines as to what's recommended and what's optional though and how apk should handle either of them being removed while the main package is installed.

I think I personally like the 3rd option the best and it seems to (somewhat) align with what you've suggested too.

Rasmus

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: Cosmo Borsky <[email-masked]>
Date: Mon, 12 Aug 2019 06:24:49 -0400

Hello Rasmus,

> we've had a discussion about that on #alpine-devel some time ago. I'd also welcome adding optional dependencies, but I'm unsure how we'd want to design this, here are some of my ideas:
Thank you for letting me know. Do you know if the logs are available for
that channel? It may be useful as a future grep source.

> I think I personally like the 3rd option the best and it seems to (somewhat) align with what you've suggested too.

To keep with Alpine's goal of being minimal, I feel like a config switch
is a little much to start with.
Optional dependencies should just be a helper for users to know which
packages to install for a certain feature. Not having optional
dependencies listed has not inhibited usage in Alpine Linux, and at most
required looking at some documentation or code to find the required
dependency for a feature.

To build off my initial idea, it may be nice to have optional
dependencies listed with  apk info , and then perhaps just a flag for
apk add  as a convenience.

apk info --depends pkg
apk add --install-optional pkg

The above should be straight forward to implement, and package
maintainers should not be required to add optional dependencies.

---
cosmo

---

From: Natanael Copa <[email-masked]>
Date: Thu, 22 Aug 2019 10:01:52 +0200

On Mon, 12 Aug 2019 06:24:49 -0400

> apk add  as a convenience.

Should the optional dependencies be listed or not? How should it
display which deps are hard dependencies and which are optional?
Wouldnt it be better with something like:

apk info --depends pkg
apk info --optional-depends

What about listing reverse dependencies?

> apk add --install-optional pkg

What should happen when you do `apk del pkg`? should it keep the
optional deps installed or should they be deleted?

What should happen if you do:

apk del optdep-to-pkg

Should it give an error or should it delete it?

Lets say you install "pkg" with optional depends as above, and then the
package maintainer adds another optional depends. What should happen
when you do the `apk upgrade`? Should the introduced optional depends
also be installed?

What if a package maintainer removes an optional dep, should it be
deleted when user do `apk upgrade` or should it be kept?

> maintainers should not be required to add optional dependencies.

It is a can of worms and I don't think its worth it.

Currently you can "clone" an install (or restore a a backup) by copying
over /etc/apk/world and run `apk fix`. What should happen with optional
depends?

---

From: Rasmus Thomsen <[email-masked]>
Date: Tue, 20 Aug 2019 23:42:25 +0000

Hello,

> Do you know if the logs are available for
that channel? It may be useful as a future grep source

It's on http://dev.alpinelinux.org . I'd recommend you to join IRC though since that's the main channel of communication.

I don't think that a config switch is non-minimal in any way (as long we don't go overboard with them), but a CLI argument would do for now.

> Not having optional

During the time I've been on #alpine-linux I've lost track of the count of users asking why XFCE looks broken by default (no icons and I think no theme even) because we don't add icons by default for the XFCE meta package (since you could install a different icon package) and can't make it recommended since we don't have that feature.

The problem with that is that we sometimes (have to?) deliver software (somewhat) broken by default (see XFCE) because we don't have something like a "recommended" dependency list. Minimalism is important for Alpine, but I feel like recommended dependencies could still fit in this if the maintainers are careful not to bloat that list.

Regards,

Rasmus