Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
On Thu, Jun 27, 2019 at 07:01:52AM +0200, Helmut Grohne wrote:
> 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.
Cool. It's been a while since I set up the current perl implementation,
not sure how much research I did wrt. other language ecosystems. I see
there's a note from doko about the Python implementation in #717433.
Anyway, sounds like the solutions are very similar which is encouraging.
BTW I'd mostly forgotten about this but we've used liblocale-gettext-perl
as a guinea pig in the archive for the current implementation, so you
might want to have a look at it. Obviously the stuff in debian/rules
should be moved to debhelper eventually.
> > 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.
I think something like this for Perl would mean major work upstream and
is unlikely to happen.
> 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?
I can see that having <cross> dependencies be an exception rather than
the norm would be good.
Unfortunately, packages building Perl extensions ("XS modules") are not
currently required to Build-Depend on anything else than "perl", which
has sort of double role as it mainly means "the set of packages for a
standard perl installation". It's currently M-A: allowed because of this
double role and doesn't seem like a candidate for M-A:same (I think).
The only M-A:same package from src:perl is currently libperl5.28, though
libperl-dev could also be made M-A:same if needed. (Despite the promising
name, libperl-dev in its current form is not the entry point needed here:
it's about building packages that embed a Perl interpreter and therefore
link against libperl.so, not about building Perl extensions.)
> 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.
This looks like the way to go, though I think it would be better to
just start it within pkg-perl packages first and amend the policy to a
'should' once there's a decent use base. Possibly 'perl-xs-build' would be
a good name but I'm happy with whatever. I suppose it could be provided
by libperl5.xx, so the dependency would be a no-op on native builds.
(Unless there's a need for a separate real package that I don't see?)
I'm not sure about the "generic concept" part as I see no benefits to this
dependency outside cross building. Consequentially, I'm not quite sure
how useful it is to add the dependency to all Perl extension packages
regardless of whether they are otherwise cross buildable or not. But
maybe there's worth in keeping those things separate and divide the big
aim into smaller steps?
I see ~500 source packages in the archive building XS modules (based on
binary packages dependening on perlapi-5.x.x), with the pkg-perl group
maintaining ~400 of them. So if all of them are to be touched, most of
the work unsurprisingly falls on the pkg-perl group.
My feeling is that a decent coverage (maybe 50% or so?) could be achieved
for bullseye "just" by updating the tooling and doing a mass commit
early in the release phase, so packages would acquire the dependency
when they are uploaded for other reasons.
Getting adoption to 100% for the pkg-perl packages would need a
concentrated uploading effort of course.
--
Niko
Reply to: