This seems to be because virtualbox-guest-additions-iso is in the non-free Debian repo, and the other packages don’t exist in Debian’s repos at all. It is rather unfortunate that a non-freedom VirtualBox dependency is mandatory here, seeing as ppc64 uses KVM, so the VirtualBox dependency is useless, and it forces me to enable the non-free repo, thus putting me at risk of later accidentally pulling in more non-freedom packages. The virtualbox-guest-additions-iso package is also quite big (around 38 MB), which seems quite wasteful of bandwidth for something I will never use.
What would be the preferred way to fix this? Adding a dummy dependency as an alternative, so that when virtualbox-guest-additions-iso isn’t available, it just silently doesn’t install it?
The rationale behind the addition of the VirtualBox guest additions dependencies is listed here:
The tl;dr: is that we had to switch to using the Guest Additions ISO in order to fix clipboard sharing, and we had to introduce it as a dependency so it would install itself on existing installations.
I’m not sure we support running without the non-free repo enabled, but you do have an escape hatch here; Kicksecure ships our own fork of the virtualbox-guest-additions-iso package, so you can enable the non-free repo only on Kicksecure’s repository and leave it disabled on Debian’s repository. The Guest Additions ISO is freedom software, it’s only in non-free in Debian for historical reasons (as I understand it), and the package only is in non-free in Kicksecure’s repo so that we stay close to what Debian does. Licensing-wise, this comes with no risk of installing non-freedom software.
But, that isn’t the only issue you mentioned, the other one is:
It might be possible for us to make these dependencies architecture-specific. They only really make sense on amd64 and arm64, so if we only whitelisted those architectures, ppc64el wouldn’t need to install them even if it’s technically possible.
I somewhat fear that could result in breakage for some users (apt can behave weirdly when dependencies get too complicated), and would prefer arch-specific dependencies instead. However, as a stop-gap, you can use the dummy-dependency tool to work around this until a fix is deployed.
Comment: This package has no real reason to be in non-free other than that it
is not built from source
I’m not 100% sure on this, but my understanding is that per Debian policy, freedom software that is not built from source would go in contrib, not main. That said, making the dependency specific to amd64+arm64 works for me; anyone using KVM on those two architectures who’s unhappy about the dependency can file their own complaint if they care enough.
That is my understanding also, but our archive doesn’t need to adhere to Debian’s repository structure entirely. On architectures where Guest Additions are supported, it is important that it is easily installable, and this is the easiest way to do that (especially given that we already have a very strong “everything we distribute is open source” policy).
