Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
(Picking up this thread from July, sorry for forgetting about it until now.)
On Thu, Jul 04, 2019 at 10:42:56PM +0200, Helmut Grohne wrote:
> On Thu, Jul 04, 2019 at 03:35:01PM +0300, Niko Tyni wrote:
> > 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).
>
> I'm left wondering why a standard perl installation would include 7MB
> worth of C headers but no C compiler. Likely this has good reasons and
> I'm not the first one to ask. If you happen to know a place to read up
> on the rationale, please point me at it.
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.
The perl-base and perl-doc packages are a compromise that's tolerated
but I'm not willing to stretch this further by breaking out stuff
that doesn't get installed by default.
I don't think the "missing" dependency on a C compiler has come up much
earlier, but perl does Suggest make for similar reasons.
> In the unlikely case of absence of reasons, I'm in favour of shrinking
> the standard perl installation. Of course these headers would be needed
> for building xs modules, so doing this would come at the cost of adding
> a new Build-Depends to (you counted) 500 source packages.
Hm. I hadn't really considered separating out the C headers from
libperl5.xx until now.
It does seem possible that cross building XS modules could work with just
the host architecture Config.pm and the C headers rather than the full
contents of libperl5.xx. This needs a bit of experimentation.
[...]
> Let me try to build consensus here from what we've learned thus far:
> * We'll have to do "something" about perl-cross-config as it presently
> does not "work".
> * The things that liblocale-gettext-perl's debian/rules does should be
> handled by debhelper.
Ack.
> * 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.
> 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.
> * Having libperlX.YZ provide the new name is going to be problematic
> during perl transitions as the package will be provided by multiple
> libperlX.YZ, but only the one matching perl can be used. I guess we
> need this to be a real package.
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.
> * 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.
> * Can we retire the virtual perl-cross-config package?
I think so.
> * 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.
--
Niko
Reply to: