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

Multiarch and interpreters

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
    - 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   ntyni@debian.org

Reply to: