[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.

Reply to: