Bug#949789: libcdb-file-perl FTCBFS: computes a build architecture ARCHLIB

[Niko Tyni]

On Sat, Jan 25, 2020 at 06:09:29AM +0100, Helmut Grohne wrote:
> Source: libcdb-file-perl
> Version: 1.00-1
> Tags: patch
> User: debian-cross at lists.debian.org
> Usertags: ftcbfs
> 
> libcdb-file-perl fails to cross build from source, because its ARCHLIB
> variable is computed for the build architecture rather than the host
> architecture. We've already seen this pattern in #949266. The same fix
> works here.
> 
> Can we take the opportunity to step back? Clearly embodying these runes
> into many packages is going to cause pain down the road. They're hard to
> remember and longish. If setting up ARCHLIB is a common thing, then
> maybe it should be centralized somehow? dpkg provides
> /usr/share/dpkg/*.mk. Maybe perl should do something similar? Could
> there be some perl.mk to be included in debian/rules that sets up
> ARCHLIB?

Thanks for looking at this.

Determining vendorarch (ARCHLIB is a bit of a misnomer) in debian/rules
is unfortunately a somewhat common idiom. My unchecked guess is that
a few dozen packages in the archive do this. The specific usage in
libcdb-file-perl (removing a file installed to vendorarch after the
build) could be circumvented with a wildcard afaics, but I don't think
that works for the general case.

I guess this can't be provided by debhelper perl_* build systems because
the vendorarch path needs to be available to the top level make and the dh
subprocesses can't affect that.

So I'm OK with centralizing this somehow in perl-xs-dev (aka. libperl-dev).
Not sure about the details yet, like where the .mk snippet should go
and what else should be included etc. Happy for any suggestions and
patches. A wishlist bug against perl might be a good place.

Once this is finalized, the Perl policy could probably use a mention about
the recommended way of using it around
  https://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths
which currently says

  These locations, particularly $Config{vendorarch}, may change
  if necessary[4]. Packages should use $Config{vendorlib} and
  $Config{vendorarch}, not hardcode the current locations.[5]

-- 
Niko