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

Re: Multiarching perl



Steve, could you weigh in on this?  (Context below.)  I know that dealing
with interpretor modules was sort of the next, "advanced" case of
multiarch, and I'm not sure how much you've thought about the
implications.  It seems like we're missing some machinery to designate
possible cases.

Niko Tyni <ntyni@debian.org> writes:
> On Fri, Sep 21, 2012 at 12:48:54PM -0700, Russ Allbery wrote:
>> Niko Tyni <ntyni@debian.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
> dependencies between
> -  an arch:any package embedding libperl and requiring a perl XS module;
>    example: barnowl
> and
> - 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?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: