Package: libkf5config-bin-dev
Version: 5.41.0-1
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:okular
libkf5config-bin-dev is not useful for cross compilation. Unfortunately,
I don't know how to fix it, so this bug comes without a patch. I'm sorry
about that. Still let me explain the things I understood thus far.
Observation 1
~~~~~~~~~~~~~
While building okular, I see:
| [ 8%] Generating settings_core.h, settings_core.cpp
| /usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5
/<<PKGBUILDDIR>>/conf/okular_core.kcfg
/<<PKGBUILDDIR>>/conf/settings_core.kcfgc -d
/<<PKGBUILDDIR>>/obj-mips-linux-gnu/
| /usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5: 1:
/usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5: Syntax error: "("
unexpected
| CMakeFiles/okularcore_autogen.dir/build.make:76: recipe for target
'settings_core.h' failed
This means that kconfig_compiler_kf5 was needed for execution (aka build
architecture), but was actually installed for the host architecture.
Likely some package needs Multi-Arch: foreign.
Observation 2
~~~~~~~~~~~~~
The libkf5config-dev -> libkf5config-bin-dev split is odd. Splitting
executables from a -dev package is common, but then the package
containing the executables is usually marked Multi-Arch: foreign. Not so
here! libkf5config-bin-dev is marked Multi-Arch: same. This is very
unusual as it removes the benefit of the libkf5config-dev <->
libkf5config-bin-dev split. At present, those packages could simply be
merged without regressing anything.
The Multi-Arch: same marking does have a little merit though: The
package ships most of its file on architecture-dependent paths and when
that happens, we usually use Multi-Arch: same. Just in this case it
turns out to not be useful.
Also usually the package containing the executables is called -dev-bin
rather than -bin-dev.
Observation 3
~~~~~~~~~~~~~
Simply marking libkf5config-bin-dev Multi-Arch: foreign likely is wrong
in a number of ways:
* It contains .cmake files on an architecture-dependent path. That's
not reasonable for Multi-Arch: foreign. Likely those can be moved to
libkf5config-dev. (Don't forget Breaks + Replaces!)
* The kconfig_compiler_kf5 lives on an architecture-dependent path.
That's inappropriate for Multi-Arch: foreign as well. If we add such
a marking, the path needs to be moved. Fortunately, it seems to be
referenced exclusively via a path mentioned in
KF5ConfigCompilerTargets-debian.cmake, so updating that file with
a new path might be sufficient.
* Then the question arises whether kconfig_compiler_kf5 is eligible for
being marked Multi-Arch: foreign at all. That's not a given. The
question to be asked here is whether its interface is
architecture-dependent.
Its main method to communicate with a user is the command line as
well as two input files (.kcfg and .kcgfc) and some output files. The
.kcfg file seems to be XML, the .kcfgc file seems to be some textual
variable assignment syntax and the output seems to be a C++ header
and source file. All of these are text files and that usually means
that Multi-Arch: foreign is correct.
Plan
~~~~
I think making libkf5config-bin-dev Multi-Arch: foreign is the right
approach. For consistency with other packages, it should be renamed to
libkf5config-dev-bin (optional). For the marking to be correct,
kconfig_compiler_kf5 needs to live on an architecture-independent path
(needs to be moved) and the .cmake files need to be moved to
libkf5config-dev.
Can someone make that work? Or maybe support me in figuring how to
implement that?
Helmut
