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

[Helmut Grohne]

Hi Niko,

On Sun, Dec 15, 2019 at 02:49:43PM +0200, Niko Tyni wrote:
> 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.

That's an interesting point of view. Let me try to get more context
here.

One other relevant distribution is buildroot. I found that buildroot
packages libnet-ssleay-perl for instance:
https://github.com/maximeh/buildroot/tree/master/package/perl-net-ssleay
This seems to use a "perl-package" build class:
https://github.com/maximeh/buildroot/blob/master/package/pkg-perl.mk
 -> We can see that all build tools are passed as commandline @ARGV
    assignments.

Another relevant player would be PtxDist, but they don't seem packaging
perl modules.

Yocto has a whole meta layer for cpan:
https://github.com/meta-cpan/meta-cpan
The build class here seems to be called "cpan":
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/cpan.bbclass
 -> I don't quite understand how they do cross compilation, but they
    seem to be exporting host architecture dependent PERL_INC, PERL_LIB
    and other things.

For OpenWRT there seems to be a package class "perlmod":
https://github.com/openwrt/packages/blob/master/lang/perl/perlmod.mk
 -> Like with buildroot, build tools are passed on the commandline.

If we count Debian in, this is four different Linux distributions all
trying to cross build (part of) cpan. I think this shows that moving
some of the integration upstream is worth a try. The less each and every
distribution diverges here, the less work there will be.

> 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.

I understand that you don't want to drive this. A the moment, I'm trying
to figure out what the ideal solution would be. The question of who
drives that solution is secondary to me.

> 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.

Let me disagree here. dh_auto_configure selects the right Config.pm
using environment variables. That's using an interface between the
builder and debhelper. It's Debian-specific and that's fine, because the
packaging is also Debian-specific. As soon as we call into the upstream
build system (e.g. Makefile.PL), these variable should cease to be a
relevant interface, because this interface should be
distribution-agnostic. So imo, choosing the right Config.pm based on the
environment is fine and still constitutes a single source of truth.

I don't think doing a Debian-specific addition to Config.pm for cross
building is a good solution, because it'd require patching at all ends
and maintaining those patches in Debian.  Either a solution can be
shared with others or we should keep it as simple as possible.

> 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.

If we assume that our solution cannot be upstreamed, I agree with that.
That'd make me sad though. In a number of (non-perl) occasions, I've
encountered that one of our other cross distributions had fixed a cross
build bug with a patch that wasn't upstreamable (often called
"hackfix"). I've tried sending real and upstreamable patches in such
cases to permanently get rid of the need to patch.

So I think the key here is to propose a useful interface for
communicating pkg-config and then agreeing with all other users on that
interface in order to be able to upstream the resulting per-module
patches.

I guess the next step is searching through our lib*-perl build failures
for occasions of using pkg-config. Then match those failures with other
distributions to encounter prior art and finding a common denominator. I
plan on looking into this, but not today.

Helmut