Bug#1123908: Optional libxml-parser-dev dependency of libglibmm2.4-dev poses challenges to cross compilation
Package: libglibmm-2.4-dev
User: debian-cross@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:atkmm1.6
X-Debbugs-Cc: debian-cross@lists.debian.org
Hello GNOME team and cross people,
I am observing a recurring pattern in cross build failures and seek
guidance for a better long-term solution.
A number of packages use gmmproc from libglibmm2.4-dev. Using this tool
requires libxml-parser-perl, but since that tool is an optional
component of libglibmm2.4-dev, there is no dependency.
Question 1: Should libglibmm2.4-dev at least declare Suggests:
libxml-parser-dev?
The direct dependency on libxml-parser-dev poses a challenge to cross
compilation, because it is interpreted to mean a host architecture Perl
extension module. This is all right on the Perl side. libxml-parser-dev
does provide an architecture-dependent interface. It cannot reasonably
be declared Multi-Arch: foreign. The gmmproc tool uses XML::Parser in an
architecture-independent way, but there presently is no way to express
"I need gmmproc" to the dependency system. Therefore most packages that
use gmmproc presently declare Build-Depends: libxml-parser-perl.
The naive solution to this problem is recognizing that XML::Parser is
meant to be run during build and annotating it :native. I think some of
the packages already do this, but to me that solution does not look
sustainable, because it adds non-obvious complexity to the GNOME
maintainers and they typically do not add :native to new packages. I do
not blame them.
So one option here would be to prominently document that a
libxml-parser-perl build dependency should be annotated :native when it
is used for gmmproc. Lintian could be extended to flag a
libxml-parser-perl <!nodoc> dependency lacking :native. That would catch
some of them, but not all.
Another way of looking at this would be adding a new binary package
(virtual or real) that may express the desire to run gmmproc. It could
simply be named "gmmproc".
Yet another way would be giving up on the optional part and ensuring
that gmmproc always works when libglibmm-2.4-dev is installed. This
amounts to making it depend on a native libxml-parser-perl (as opposed to
suggesting it).
Question 2: How do you prefer to express the need to run gmmproc during
build?
A. Continue adding libxml-parser-perl dependencies, but annotate them
all :native. This needs to be well-documented and maybe lintian could
warn about unannotated libxml-parser-perl <!nodoc> dependencies. That
would still hit some.
B. Use a higher level mechanism such as Build-Depends: gmmproc to
express this need hiding the implementation detail that
libxml-parser-perl is being used.
C. Have libglibmm-2.4-dev always ensure a working gmmproc turning the
libxml-parser-perl requirement into a non-optional dependency.
Depending on libxml-parser-perl is a non-trivial matter, because gmmproc
lives in an architecture-dependent package. If libglibmm-2.4-dev were to
Depends: libxml-parser-perl, it would simply become unusable to cross
compilation. It also cannot Depends: libxml-parser-perl:native (because
:native is only permitted in Build-Depends) nor Depends:
libxml-parser-perl:any (because libxml-parser-perl is not Multi-Arch:
allowed). An intermediate Multi-Arch: foreign package is required to
achieve this. A naive way could be adding
libglibmm-2.4-implementation-detail being Arch:all + M-A:foreign +
Depends: libxml-parser-perl and then having libglibmm-2.4-dev Depends:
libglibmm-2.4-implementation-detail to implement option C above. If
going for option B, gmmproc could also be moved to that package and we
could name it gmmproc2.4 instead. However, since it is Arch:all, we must
also move gmmproc out of /usr/lib/${DEB_HOST_MULTIARCH} into one of
/usr/share, /usr/libexec or /usr/lib (without multiarch). This can be a
challenge unless we can centrally control the location where gmmproc is
being found.
I appreciate feedback on how you see us moving forward with this. If
this mail is unclear, please do ask questions. These cross problems
typically can only be solved by combining deep package knowledge with
extensive cross build experience. I am not aware of anyone possessing
both.
Helmut
Reply to: