Re: Multiarching perl
Hi!
[ Not subscribed, M-F-T set, please CC. ]
On Sun, 2012-09-23 at 22:20:09 +0300, Niko Tyni wrote:
> 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.
Will try to clarify some things, w/o getting into specifics on how
perl should be “multiarch-ified”, as I've not checked the details.
When we added the M-A:allowed value it was precisely for the case of
interpreters that could load both arch-specific plugins/modules,
and arch-indep scripts. So whatever package ends up with the perl
interpreter needs to be marked as M-A:allowed.
> 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'.
The other reason for the M-A:allowed value was to avoid changing the
semantics of the relationships, implying a mass marking and change
of semantics on a flag day. So adding :any qualifier needs to be
done only to loosen up the relationship, as the default is a tight
arch:foo → arch:foo only. The reason we decided to initially treat
arch:all as ~ native, was to avoid strange situations with stuff like
pkgA_arch-foo → pkgB_arch-all → pkgC_arch-bar, or possible automatic
cross-grades by frontends if one of the arches is no available, and
because relaxing this later on, would not be an issue, but reverting
it would. So if this causes actual problems for things like perl
modules, or just to avoid having to mark tons of perl and python
modules, then it probably makes sense to relax this after wheezy is
out, after having considered this a bit more for other possible
drawbacks.
The only perl-using packages that would need their depedencies to be
arch-qualified with :any, would be arch:any packages that just call
the interpreter and do not require any linking.
> 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
This in principle would be fine w/o any marking, the default would do
the right thing.
> and
> - an arch:any package that has a /usr/bin/perl script that requires
> a perl XS module; example: devscripts
And this package (AFAICS) is just arch:any because of the tiny C wrappers,
the rest of the scripts just use the interpreter side of perl or python,
so those dependencies would be relaxed with :any arch-qualifiers. The
dependencies between the XS modules and perl itself would be resolved
between them.
> 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).
So this should not be a problem, as long as I've not misunderstood the
examples.
> 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?
:native makes sense mostly (if not only) for cross-build-dependencies.
thanks,
guillem
Reply to: