Re: perl extension modules and Multi-Arch: foreign
Hi Niko,
On Sun, Dec 15, 2019 at 11:21:31AM +0200, Niko Tyni wrote:
> [Forking from #946655 and dropping the bug]
Hmm. I'm not sure I like this fork, because you're asking very relevant
questions here.
> 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.
I think the "multi-arch interpreter problem" is something subtly
different or it got used with different meanings. What I usually mean
when referring to it is an architecture-independent package that needs
to transfer an architecture constraint down to its dependencies.
Typically such a dependency is on the interpreter and the
architecture-independent package is a pure language module.
The "extension modules must not be marked Multi-Arch: foreign" issue is
kinda orthogonal to that. It's related, but it can persist even after
solving my variant of the "multi-arch interpreter problem".
> 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.
Yes. This is a very good example.
> 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.
I was wondering about this question for some time already and my
conclusion on coinstallable embedded interpreters basically was:
* I don't need this.
* Some day somebody will want this.
* I don't want to be the one who breaks it at an architecture level.
> 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 do see demand popping up every now and then, but I don't see anyone
investing the time to do it properly. #943811 seems completely wrong to
me as their reasons for changing things seem to be "debootstrap does not
handle Multi-Arch".
> 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.
I agree that we could do that. I'm less sure that we should do it. I
fear that at some point we'd realize that allowing a foreign embedded
perl would be useful and rolling back this change would be harder. For
this reason, I tended to defer these questions (aka wait for more
knowledge).
> Does that make sense? Is there an actual use case for coinstallable
> embedded Perl interpreters for multiple architectures?
I think this is the right question to ask. When it comes to answering
it, I'm less sure. Let me provide some arguments though:
* libperl is embeddable today into foreign applications, because
libperl5.30 can be coinstalled for a foreign architecture. Changing
this conceptually is a regression and risks breaking what people
actually use. That said, I don't have any concrete evidence.
Consequences of forbidding foreign embeddable perl:
* libperl5.30 shouldn't be Multi-Arch: same.
* Cross-grading Debian (which is barely supported at best) would become
more difficult. One thing that makes cross grading difficult is the
concept of a "native" architecture. At the point where one
cross-grades dpkg, the "native" architecture suddenly flips and with
it all "Architecture: all" packages. Essentially, forbidding a foreign
embeddable perl would mean binding it to the "native" architecture
making this problem worse.
* We could mark much of the perl universe Multi-Arch: foreign.
* Fully forbidding a foreign perl is not entirely possible. You can mix
essential packages from multiple architectures. Therefore installing
a foreign perl-base is possible in principle. It'll not work
practically at present, because debconf (an essential arch:all
package) currently depends on perl-base and thus locks it to the
native architecture, but I consider that as an implementation detail
as debconf could be using perl-base:any. Once we assume perl to be
native, a lot of bad things will happen in such a situation.
Consequences of allowing foreign embeddable perl:
* The provided perl modules from the perl binary package should be
moved to some Multi-Arch: same package.
* A possibly large number of pure perl modules would need to work
around the multi-arch interpreter problem by switching them from
Architecture: all to any and adding Multi-Arch: same.
https://people.debian.org/~helmutg/multiarch_interpreter.html says
we're talking about orders of 450 packages.
https://bootstrap.debian.net/ma_interpreter.html has a better
analysis (finding more affected packages), but doesn't give stats for
perl. I guess the number is larger than 500. This can be
demand-driven though.
* We want perl modules (pure and extension) to *not* depend on perl.
This may sound strange at first, but that's absolutely required for
using them with a foreign (embedded) perl. Instead, anyone using perl
modules needs (and already does) depend the perl interpreter (whether
embedded or not) and the modules must depend on the modules they use
(e.g. those shipped inside libperl5.30 and provided by perl).
* I'm very unsure about how we can improve the situation of pure perl
modules. Their perl dependency will be replaced by something else, so
the question of whether to annotate that dependency with :any or not
no longer arises. It likely is impossible to mark pure perl modules
Multi-Arch: foreign though. If such a need arises, the module should
be switched too Architecture: any + Multi-Arch: same (see earlier).
However, for many concrete examples we don't actually need to solve
this. The apache2-dev case that brought us to this discussion does have
an easy workaround: Move the pure perl modules into a new binary package
and mark that package Multi-Arch: foreign. It's safe here, because the
module is a plugin to debhelper, which will include all required
modules. Then have apache2-dev depend on the new package. Very often,
such issues can be solved by splitting packages into smaller components.
I guess you are none wiser now.
Helmut
Reply to: