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

perl extension modules and Multi-Arch: foreign

[Forking from #946655 and dropping the bug]

On Thu, Dec 12, 2019 at 10:17:32PM +0100, Helmut Grohne wrote:

> A perl module that depends on an extension (even indirectly)
> must not be marked Multi-Arch: foreign.

While we're on the topic, I'd like to revisit this assertion a bit. As
I understand it, this is the 'multi-arch interpreter problem': if Perl
extension ("XS") module packages were Multi-Arch: foreign, dependency
chains could lose architecture restrictions and systems could end up
with extension modules unusable with the Perl interpreter that tries to
load them.

An example in the archive is barnowl, which links against libperl but is
currently uninstallable for non-native architectures because it depends
on a number of XS module packages. If those were Multi-Arch: foreign,
the package would be installable but the libperl embedded interpreter
couldn't use the XS modules. We don't want that to happen.

I'm wondering if coinstallable embedded Perl interpreters for multiple
architectures are useful in the first place and whether we should
prevent that. This would enable Multi-Arch: foreign Perl module packages
throughout, as all Perl interpreters on the system would then always be of
the same architecture.

There seems to be a demand for this because Perl module dependencies
currently make some applications uninstallable for non-native
architectures even though they're just using the /usr/bin/perl interface
to load them. #943811 is the latest (if somewhat confus{ed,ing}) example
of this.

I'm thinking we could decree that packages embedding Perl need to depend
on perlapi-*, and change dh_perl to generate those. (Of course there'd be
a transition period etc. but there are just 50 or so packages affected.)
This would make them only installable for the native architecture, as
perl-base is the only thing providing perlapi-*, and it is not marked
for Multi-Arch.

Does that make sense? Is there an actual use case for coinstallable
embedded Perl interpreters for multiple architectures?

Reply to: