Re: Multiarching perl
On Fri, Sep 21, 2012 at 12:48:54PM -0700, Russ Allbery wrote:
> Niko Tyni <firstname.lastname@example.org> writes:
> > In the wider view, do we need to (eventually) add M-A tags on all the
> > perl module packages in the archive to make things like a foreign
> > architecture irssi perl plugin generally usable?
> Yes, probably.
> > Can an arch:all perl module package be M-A:foreign? What if it depends
> > on an arch:any perl module package?
> Indeed, I think this doesn't work properly. M-A:foreign would allow a
> non-native version of the arch:any Perl module package to satisfy its
> dependency, but that wouldn't actually work if one were running Perl in
> the native architecture.
> That does feel like a hole.
Yes. The remaining alternative, setting M-A:allowed on arch:all Perl
module packages depending on arch:any ones, wouldn't work either
AFAICS. The spec says arch:all packages are treated as native ones,
and M-A:allowed just adds the :any qualifier. What we need is 'the
dependencies must match this architecture', not 'the dependencies can
be of any architecture'.
Another hole I'm seeing is that there's no way to differentiate the
- an arch:any package embedding libperl and requiring a perl XS module;
- an arch:any package that has a /usr/bin/perl script that requires
a perl XS module; example: devscripts
The former needs the XS module in the architecture matching the package
itself, while the latter one needs it in the native architecture (the
one matching perl-base).
As long as we don't have something like a :native qualifier, I can't
see how the package manager can do the right thing with both cases?
Niko Tyni email@example.com