Bug#945057: libnet-dbus-perl FTCBFS: uses the build architecture pkg-config

Niko Tyni ntyni at debian.org
Sun Dec 15 12:49:43 GMT 2019


On Tue, Nov 19, 2019 at 07:50:57PM +0100, Helmut Grohne wrote:

> So we still don't have our single source of truth here.
> 
> The other aspect is that this is very much Debian-specific. Given the
> effort it takes to make stuff cross buildable, we want to (and do) share
> that work with yocto, ptxdist, buildroot and others as much as possible.
> However this transformation doesn't help any other distribution.
> 
> Last but not least, this approach breaks an important corner case. It
> happens every now and then that we need to build a build tool during a
> package build. Such build tools need to be built for the build
> architecture (to be runnable) rather than the host architecture, so it
> is the task of the build system to explicitly tell which pkgconfig files
> are requested for the build and which are requested for the host.

IMO you're expecting too much from this stuff.

I don't think the upstream Perl community even knows about these cross
build experiments. I'm not aware of any other distros working in this
area either (though I'm happy to be proved wrong).  It's all a pile of
Debian specific hacks abusing upstream features designed for other things.

Sure, it would be nice if ExtUtils::MakeMaker differentiated between
build dependencies for build and host architectures. But that would mean
proper upstream design for cross builds and all and I don't have an itch
to push that myself.

As for a single source of truth: Config.pm is already chosen based on the
(Debian specific) environment variables so I'd say that's still the single
source. I suppose I can bake the host multiarch triplet information into
Config.pm (like I did for debian_abi) if that helps, but it'd still be
Debian specific.

I think passing the right pkg-config in as an environment variable like
your patch does is quite adequate. If there are any actual cases where
the build needs the native pkg-config too, I guess that needs to be
handled as a special case.
-- 
Niko



More information about the pkg-perl-maintainers mailing list