Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
On Sat, Sep 28, 2019 at 10:15:13PM +0200, Helmut Grohne wrote:
> On Sat, Sep 21, 2019 at 11:21:27PM +0300, Niko Tyni wrote:
>
> > On Thu, Jul 04, 2019 at 10:42:56PM +0200, Helmut Grohne wrote:
> > The background here is that upstream has a strong opinion that installing
> > "perl" should pull in the full upstream installation (including the C
> > headers needed to build XS modules), and that users should not encounter
> > systems with /usr/bin/perl but not the full installation.
>
> Thank you for the rationale. Is that with Recommends or without?
I don't think that has come up. We're not using Recommends at the
moment. The main thing here has been about perl-base not becoming
the 'normal' perl installation on user systems.
> > > * To facilitate cross building of xs modules, we'll have those xs
> > > modules gain a new build dependency. This dependency has to ensure
> > > that the host architecture Config.pm is available.
> >
> > It must also pull in at least the host architecture C headers, and
> > possibly some other stuff currently in libperl5.xx.
>
> Let me clarify: libperl5.xx presently has the host architecture C
> headers. The new build dependency very likely needs to depend
> libperl5.xx (host) anyway, so what you are saying here is that you
> intend to move things out of libperl5.xx. Is that correct?
'Intend' is too strong at this point. I guess I was thinking of ways to
save cross builds pulling in the whole libperl5.xx (host) when all they
presumably need is the C headers and Config.pm. But I now realize that
would make packaging so complex that it's not worth it; see below.
I can come up with three different implementations for perl-xs-dev.
In order of increasing complexity:
A. have libperl5.30 Provide perl-xs-dev, continue shipping
/usr/lib/<triplet>/perl/cross-config-5.30.0 there (the path
could be renamed if desirable)
B. make a real perl-xs-dev package that Depends on libperl5.30, have
perl Depend on perl-xs-dev (= ${binary:Version}), and possibly move
/usr/lib/<triplet>/perl/cross-config-5.30.0 there
C. make real perl-xs-dev and real perl-xs-dev-5.30 packages,
have perl Depend on perl-xs-dev (= ${binary:Version}),
have perl-xs-dev Depend on perl-xs-dev-5.30,
have libperl5.30 Depend on perl-xs-dev-5.30,
and move things required for XS module cross building like the C
headers and /usr/lib/<triplet>/perl/cross-config-5.30.0 into
perl-xs-dev-5.30
Option A has the downside that once we move to Perl 5.32, a lingering
libperl5.30 will satisfy build dependencies on perl-xs-dev (host) but not
work with the build perl. Option B fixes that. Option C optimizes disk
space for cross builds so they don't have to install the whole libperl5.30
(host) when they just need the bits in perl-xs-dev-5.30 (host).
I think we can do A straight away and B soon. C is clearly overkill,
too complex for its limited benefit.
> Ok, let's move this to consensus then. Can you add the perl-xs-dev
> binary package soonish such that we can use it in Build-Depends as soon
> as possible (even if it still lacks essential functionality). In
> principle, having libperl5.xx provide it could do initially. That'd
> allow reducing the long tail of the update of Build-Depends.
I'm adding Provides: perl-xs-dev (so option A above) for 5.30.0-7,
and removing the perl-cross-config virtual package.
--
Niko
Reply to: