Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
Hi Niko,
On Thu, Jun 27, 2019 at 12:02:52AM +0300, Niko Tyni wrote:
> For cross builds, the host architecture version of Config.pm needs to
> be on the Perl search path before the build architecture version one.
> However, we can't just point the build architecture Perl at the host
> architecture modules directory because any binary modules (for example
> Cwd) in there will not be functional.
This is similar to how Python 2.x does it. The directory to put on the
search path is /usr/lib/python2.7/plat-<archspecific>/ and the module to
import is called _sysconfigdata_nd.py there. I've also seen something
similar in the ruby world, but don't remember the details currently. I'm
explaining this here, because I hope we can learn from them.
> So we need to ship a directory with just Config.pm and let the build
> architecture perl use the build architecture modules for all other
> tasks. Somewhat surprisingly this seemed to work, at least in my limited
> tests.
Exactly how Python 2.x does it. In 3.X, the module is on the standard
search path and has an architecture-dependent name. This approach has a
distinct advantage: You can import the module for two architectures
(e.g. build and host) simultaneously in theory. I haven't actually seen
anyone using this, so the current approach for perl is likely good
enough.
> One piece that I haven't got in place yet is how the cross build should
> pull in the host architecture libperl5.28 package (which contains
> /usr/lib/<arch>/perl/cross-config-5.28.1/ with Config.pm). We definitely
> don't want build dependencies with hardcoded Perl versions on the
> packages. I originally had libperl5.xx Provide perl-cross-config with
> the idea that builders could depend on that, but I see I've since moved
> that Provides entry to perl (along with others due to #899110). I think
> this move was probably wrong and made the perl-cross-config virtual
> package useless.
Again, let me compare this to the Python world. The config module is
shipped with libpythonX.Y-minimal (ignore the -minimal part), which is
similar to how perl does it. When packaging Python extensions, it was
common to Build-Depends: python-all-dev (or for one version python-dev).
For cross building we now have to replace that with libpython-all-dev,
python-all-dev:any and this is a pain. If we can fix this for perl
without updating each and every build dependency, that would be great.
> Even with that fixed, adding build dependencies on 'perl-cross-config
> <cross>' to all the XS module packages we're targetting with this seems
> like a rather arduous undertaking, but doable for bullseye if this is
> deemed to be the right approach.
I'd like to avoid <cross> dependencies whereever reasonable. I think
they should be an exception and not a common case, because it is
something that we easily get wrong. It is often easier to use a M-A:same
package as the "entry point" and forward to M-A:foreign packages from
there. Things that are in the M-A:same dependency tree get installed for
the host architecture. Things that are in the M-A:foreign subtree get
installed for the build architecture. For Python it would have been
possible to subtly reroute dependencies such that python-all-dev would
become M-A:same instead of M-A:allowed, but we didn't do that. Now the
imporant question kinda is: What is this "entry point" for perl? What is
the common dependency for all perl extensions? Is there one? Can we
repurpose it in this way?
If that's not possible and we have to update each and every perl
extension, I'm in favour of fixing this in a more generic way. I suggest
updating the perl policy to say that every perl extension must build
depend on e.g. perl-ext-build (name up to colouring). This is not
cross-specific in any way, but a generic concept. Then we can use that
dependency to implement the cross case without bothering maintainers.
Such a rule should be lintian-enforced eventually.
The gist of this is that I try to make cross builds and native builds
differ as little as possible. Maintainers shouldn't have to remember the
cross use case. Rather, it should just work. It should be as close to
the normal processes as possible.
So I think that the first step is getting this dependency issue sorted
out in a conceptual way. Still the present discussion has already gotten
us quite far.
Thank you
Helmut
Reply to: