Package: libdap-dev
Version: 3.20.7-7
Severity: important
User: [email protected]
Usertags: ftcbfs
Control: affects -1 + src:gadap
Hi Alastair,
your -7 upload of src:libdap included a tiny change that is entirely
missing from debian/changelog: It replaces /usr/bin/dap-config with a
version written by you that works by deferring to pkg-config. You cite
multiarch as a reason to replace dap-config.
Unfortunately, your change has the reverse effect. While dap-config used
to work in a multiarch setting, with your replacement dap-config
multiarch is broken. That may sound surprising, so let me explain.
With the old dap-config, all the architecture-dependent paths were
embeded in /usr/bin/dap-config, whose path is architecture-independent.
For that reason, you couldn't mark libdap-dev Multi-Arch: same. With
your replacement dap-config, it is the same for all architectures, so
you could mark it Multi-Arch: same. Unfortunately, it also completely
breaks dap-config for foreign architectures. Just why?
Your new dap-config defers to pkg-config. It doesn't tell pkg-config
which architecture you are compiling for though, so pkg-config makes
just uses whatever architecture it was installed as. When that
architecture happens to differ from the libdap-dev architecture, it
fails to find any .pc files. So in effect, whenever you install
libdap-dev for a non-native architecture, it is bricked.
In effect, your change made us go from
You can install libdap-dev for any single architecture, but not two.
to
You can install libdap-dev for as many architectures as you want, but
it'll only work on the native one.
In particular, this completely breaks any cross building that uses
libdap-dev.
I see two major options here:
a) Delete dap-config and go without it. Any dap-config users (e.g.
gadap) need to be converted to using pkg-config.
b) Revert your change and drop Multi-Arch: same from libdap-dev. As bad
as this may sound, it doesn't actually break that many practical use
cases as coinstallability of -dev packages is rarely required.
I recommend option a as a long-term fix and option b as a short-term
fix.
Is it also possible to retain M-A:same and keep dap-config?
Unfortunately, no. dap-config needs to know which architecture it was
called for, but that information is not transferred in the dap-config
call. It has no chance knowing. pkg-config solves this by using
<triplet>-pkg-config. It knows the intended architecture from its own
tool prefix. When doing so, you must replace all those AC_PATH_PROG that
search for dap-config with AC_PATH_TOOL, but really, just go
PKG_CHECK_MODULES and be done.
Helmut
