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