Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
Hi Niko,
On Tue, Oct 15, 2019 at 04:29:31PM +0300, Niko Tyni wrote:
> 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.
I take that as "without Recommends".
> > 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)
As you point out later, this option will break horribly during perl
transitions. It's going to be a pain for as long as two libperls are
around. This is fine as an intermediate solution, but not for long term.
> 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
Seems reasonable to me. Even without moving the file.
> 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
I had to read it twice to understand it.
> 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).
Optimizing for disk space seems like a non-goal to me here. The build
machines are assumed to be big and fast. We want to make it work (at
all). If there were a way to choose a perl version to build modules
against (like with python), this approach would make some sense, but we
tend to not keep multiple perl versions around for too long.
> I think we can do A straight away and B soon. C is clearly overkill,
> too complex for its limited benefit.
Agreed.
> > 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.
Thank you. Once this is there, we can as gregor and others to use
perl-xs-dev in Build-Depends. :)
I guess the next important bit is the debhelper support to tell the
build system about the cross config.
Helmut
Reply to: