'Architecture: all' with architecture specific dependencies - the Depends field contains an arch-specific dependency but the package is architecture all
I am maintaining two Debian derivatives distributions, Whonix and
Kicksecure. (Open Source) I hope you don't mind my question.
I am trying to build a custom meta package with 'Architecture: all' that
has an architecture specific dependency:
Package hardened-malloc is only available for amd64 and cannot be
trivially ported. (Would require source code level changes which I am
unable to contribute.) That package is not all that important. We want
it pre-installed on amd64 but at the same time it shouldn't be a blocker
for ports to let's say arm64.
(We got ported to to arm64 and ppc64 earlier before we introduced
architecture specific packages.)
Here is a simplified example.
Description: Dependencies for hardened systems CLI
A metapackage, which installs command line interface (CLI) packages
which should be installed on hardened systems.
debhelper fails with the following error message
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-Pdebian/kicksecure-dependencies-cli -UMulti-Arch returned exit code 255
> dh_gencontrol: Aborting due to earlier error
> make: *** [debian/rules:9: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
'Recommends:' does not fit either since we're using apt with
'--no-install-recommends' during the build process to have tighter
control about which packages get installed.
Can I somehow hack or work around that limitation?
I could use 'Architecture: any' but then that meta package would be
build and added to the repository as 'amd64', although it's "mostly"
just a 'Architecture: all' package, except for the "optional dependency".
This would mean that either,
- architecture users other than amd64 couldn't simply install our meta
package by simply adding our third party repository and apt installing
from it, or
- I'd have to build that package for all platforms and add to
repository. That's doable in theory but would require a lot of
cowbuilder chroots, disk space and build time.
("99%" of our packages are "really" 'Architecture: all', i.e. just
configuration packages, bash or python.)
Hence, I am looking for a simpler fix. Any idea?