[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

'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:
hardened-malloc [amd64]

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.

Package: kicksecure-dependencies-cli
Priority: required
Architecture: all
Depends: ...,
 pkg1,
 pkg2,
 ...,
 hardened-malloc [amd64],
 ${misc:Depends}
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

>    dh_gencontrol
> dpkg-gencontrol: error: the Depends field contains an arch-specific
dependency but the package is architecture all
> dh_gencontrol: dpkg-gencontrol -pkicksecure-dependencies-cli
-ldebian/changelog -Tdebian/kicksecure-dependencies-cli.substvars
-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?

Kind regards,
Patrick


Reply to: