On Fri, Apr 18, 2014 at 07:11:56AM +0200, Guillem Jover wrote:
> After my warning [W] about this subverting the dependency system was
> willfully ignored, I concluded trying to do anything else about it
> was a waste of time and energy.
>
> [W] <https://lists.debian.org/debian-devel/2013/04/msg00578.html>
It seems to me that an interpreter supporting DSO language extensions
can have multi-arch support at several different levels. I think
this classification might explain why the current python multiarch
implementation hasn't encountered the above problems.
The levels I see are
1) multiarch annotations for /usr/bin/interp, but no Multi-Arch:same
packages. The architecture of /usr/bin/interp must match the
architecture of any corresponding embedded interpreter packages [1]
(containing libinterp.so.*) on the system. Packaged DSO extensions
must obviously match this architecture too.
2) Multi-Arch:same embedded interpreter packages (with the standard
library), but separately packaged DSO extensions can be installed
for only one architecture at a time
- makes a somewhat wider set of non-native packages installable than 1)
(those depending on the embedded interpreter package)
- the dependencies of DSO extension packages guarantee that their
architecture matches the /usr/bin/interp package
- how useful are the embedded interpreters on architectures not
matching /usr/bin/interp, when you can't install packaged DSO
extensions for them?
3) Multi-Arch:same embedded interpreters (+stdlib), but packaged DSO
extensions aren't limited to one architecture (and could be
Multi-Arch:same)
- this would be the "full" multiarch implementation
- DSO extension packages depend on the embedded interpreter packages
(and probably on the /usr/bin/interp package without :any as
an alternative)
- currently fragile/broken due to our dependency system limitations
(see Guillem's link above)
I think python3 is doing 2), and ruby2.0 seems to be trying to do 3).
I'm currently contemplating whether to do 1) or 2) for perl. I'll
follow up on that in a separate mail.
I hadn't fully realized the difference between 2) and 3) until now,
so I hope this is useful for somebody else too.
This comes from a perl background, where packaged DSO extensions depend
on perlapi-* and the perl source package could control who provides
it. Possibly the dependencies of packaged DSO extensions for other
interpreters don't have a similar point of control. I suppose that this
would make the line between 2) and 3) more blurry and call for policy
and/or helper support to avoid premature takeup on 3) before its problems
are resolved.
Does this make sense?
[1] I'm assuming that linking against libinterp.so.* is only used for
embedding an interpreter, not for utility functions or the like.
I think this is true for perl. If it doesn't hold for other
interpreters, I'd be interested in examples.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140502141448.GA7566@estella.local.invalid
