Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
Hi Niko,
On Sat, Sep 21, 2019 at 11:21:27PM +0300, Niko Tyni wrote:
> (Picking up this thread from July, sorry for forgetting about it until now.)
Thank you!
> 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 the "missing" dependency on a C compiler has come up much
> earlier, but perl does Suggest make for similar reasons.
I wouldn't suggest it either, because we don't have working toolchain
dependency translation yet.
> > * 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?
> > Then non-consensus:
> > * We need to decide the name of the new dependency. I vaguely proposed
> > perl-ext-build, but am now unconvinced of that. You refined it it to
> > perl-xs-build. I am now convinced that the -build suffix is not a
> > good idea as we usually call this -dev. What about perl-xs-dev?
>
> Works for me.
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.
> So if I get this right, we'd put the C headers and a copy of Config.pm
> into perl-xs-dev, which would be M-A:same. libperl5.xx would then
> Depend on perl-xs-dev (= ${binary:Version}). XS module packages would
> Build-Depend on perl:any for ExtUtils::MakeMaker and the rest of the
> Perl standard library for the build architecture, and perl-xs-dev for
> Config.pm and the C headers for the host architecture.
>
> I think this could work.
I'm not sure that the C headers have to live in perl-xs-dev, but they
certainly need to be provided somehow (e.g. via a dependency). Turning
it M-A:same seems very much necessary if a standard perl installation
must pull the native perl-xs-dev.
> > * Who is going to write the debhelper patch? I think I'd be able to do
> > it, but I presently lack the time to do it. Do you want to handle
> > this, Niko?
>
> Not much time here either, but I can see this task naturally falls on me.
>
> So yeah, I'll try to handle this but I'm obviously happy if somebody
> else wants to take over.
I'm happy to review the implementation (or drafts thereof), but I don't
think I know sufficient aspects of perl to do it myself.
> > * Can we retire the virtual perl-cross-config package?
>
> I think so.
Please go ahead. There aren't any reverse dependencies left.
> > * We still disagree on whether all xs modules should carry the new
> > dependency or whether only those that are cross buildable should have
> > it.
>
> No strong disagreement here, and we can have the 'should' vs. 'must'
> discussion later.
Seems reasonable to me.
Thank you for moving this forward.
Helmut
Reply to: