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

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

> 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.


Reply to: