Re: Multiarching perl
On Tue, 2012-11-20 at 22:58:09 +0200, Niko Tyni wrote:
> On Sun, Nov 18, 2012 at 11:52:50PM +0100, Guillem Jover wrote:
> > 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.
>
> Thanks for this, much appreciated.
You're welcome!
> I'm still trying to wrap my head around it, so I'll just pick
> on a couple of details for now.
Sure.
> > 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.
>
> Understood. There's a complication as perl-base and its /usr/bin/perl
> are Essential:yes, not sure yet how much that changes things. I suspect
> both perl-base and perl need to be M-A:allowed; perl is currently
> going to be co-installable with itself but perl-base isn't.
Anything that can load dynamically linked objects, should be considered
to behave exactly as we'd treat shared libraries, even if it supports
that dual behaviour.
As such we should be treating those packages dependency-wise as
Essential:yes, only when they are being used as an interpreter, not
when they are being used as a shared library, in the same way we
explicitly depend on pseudo-essential shared libraries when linking
against them (like libc6).
Regarding M-A:allowed, only packages that show this dual behaviour
should be marked that way, anything else should be marked either
M-A:foreign or M-A:same (or not at all).
OOC what would be the point of making perl co-installable with itself
when perl-base will not be? The .so files in perl will not be usable
for example w/o the matching perl-base:arch.
> > 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.
>
> > > - 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.
>
> I still can't see a guarantee that the XS module matches the arch of
> /usr/bin/perl?
If the package providing /usr/bin/perl is M-A:allowed and arch:foo,
and the XS module is arch:bar, and it simply Depends (w/o being
loosened with an :any arch-qualifier) on the /usr/bin/perl package,
then the arch should be guaranteed to match, and this specific case
should become an unsatisfied relationship.
> For instance, suppose we already have installed a foreign arch
> application package linking against libperl (M-A:same), and the above
> XS module package (M-A:same) on the same foreign arch, for use by this
> libperl. Won't the already installed version of the XS module package
> satisfy an :any qualified dependency? And therefore be incompatible
> with /usr/bin/perl, breaking the script?
If pkg-dynlib:amd64 depends on libperl:amd64 (which depends on
perl-base:amd64), and xs-module:amd64 depends on perl:amd64 (which
depends on perl-base:amd64). And none of those dependencies are
loosened with an :any arch-qualifier, then they are not going to cross
architecture boundaries, in the same way a normal program linking
against a shared library would not cross boundaries.
The fact that a pkg-script:all then depends on the xs-module or
perl/perl-base, would mean that it would be able to run independently
of the target architecture. The :any case would matter whenever a
pkg-invoker:amd64 is calling the perl interpreter through something
like system(2), or the package has a mix of script and compiler
program like devscript for example, in that case because the target
arch does not matter, one might want to loosen it up so that a foreign
architecture package can be installed.
> Or is there a guarantee that a hypothetical
> Depends: perl-base:any, libxs-whatever-perl:any
>
> would pull in both packages on the same architecture?
I'm not sure I understand what you mean here. Maybe if we talked about
an actual specific set of packages it might be easier to see how this
might play out?
> (For now, I'm deliberately ignoring the fact that perl-base is Essential:yes
> and therefore no package currently needs to depend on it.)
See above, packages making use of the dynamic linking side of it, do
need to depend on it (and AFAICS most if not all actually do right now).
Hope this shed some more light.
Thanks,
Guillem
Reply to: