Re: multiarch and interpreters/runtimes
On Fri, Apr 19, 2013 at 12:33:07AM +0200, Guillem Jover wrote:
> As I pointed out on the debian-perl mailing list, after having
> discussed about multiarch support for perl, I don't think a fully
> multiarchified perl (nor at least python) should be uploaded to sid,
> as going full multiarch on the combination of a program frontend to an
> interpreter in shared library form, plus architecture dependent modules
> makes for situations that can bypass the dependency system and get
> into broken installations. Please see [0] for more details, although
> the "solution" I proposed is bogus and would not solve much as that
> does not help with arch-dep modules being depended by arch-indep ones
> and being run through the shared library interpreter, because the
> dependency to match is against the running interpreter, not just the
> program one.
>
> [0] <https://lists.debian.org/debian-perl/2012/12/msg00000.html>
>
> I've not checked the situation with other interpreters, but if they
> are similar to perl/python then doing full-multiarch might be a bad
> idea too for those. I think the full-multiarch support for python in
> experimental should really be reverted.
Incidentally I discussed this with wookey on #multiarch recently. I
asked him to review a proposed solution before exposing it to a wider
public, but apparently he was unable to allocate enough time yet, so
you, dear -devel readers, will have to do that. What follows is my
thoughts from that discussion.
The background is nicely summarized by Guillem Jover at
http://lists.debian.org/debian-perl/2012/12/msg00000.html. I'd like to
revisit this little footnote from the multiarch spec:
https://wiki.ubuntu.com/MultiarchSpec#fnref-b110b386874a9b24eaecd36fa24653a467ee27c4
It essentially claims that a particular way of resolving dependencies
(explained below) is impossible to do with dpkg. Let us assume dpkg not
to be a limitation here and see what would happen.
Let us assume that in addition to an Architecture each binary package
gains two sets of /virtual architectures/ and /running architectures/.
These are not fields in the binary package. They are sets of regular
architectures. Both are to be computed dynamically by the resolver. In
addition we change the rules for dependency resolution. This affects
especially dependency resolution involving Architecture:all packages.
Rules for dependencies and computation of virtual architectures and
running architectures:
* "all" is never a member of virtual or running architectures.
-> Running architectures:
* Start with the set of architectures known to dpkg.
* If the package has a real architecture (i.e not "all"), intersect
with the singleton set of that architecture.
* For each dependency which is not marked :any compute the set of
virtual architectures and intersect.
* The resulting set is considered the running architectures. If it
is empty the dependencies are considered unsatisfied.
-> Virtual architectures:
* By default equal to the running architectures.
* If the package is Multi-Arch:same, use the union of all running
architecture sets of packages with the same name installed.
* If the package is Multi-Arch:foreign, use the set of architectures
known to dpkg.
Usually non-data packages would have exactly one running architecture. I
had a hard time coming up with an example where this is not the case. It
is fakechroot.
Let us visit some examples from Guillem's mail to show how this could
fix some of the problems:
,--> libperl:amd64
prog-link:amd64 +--> perl-xs-module-a:amd64
`--> perl-pm-module-a:all --> perl-xs-module-b:i386
We would ensure that perl-pm-module-a has no M-A:foreign set. Then
perl-pm-module-a would have running and virtual architecture i386. The
set of running architectures of prog-link is a subset of the
intersection of its own architecture (amd64) and perl-pm-module-a's
virtual architecture (i386) and thus empty. Its dependencies would not
be considered satisfied.
,--> perl-xs-module-a:i386 (M-A:same)
perl-script:all +--> perl-xs-module-b:amd64 (M-A:same)
`--> perl:amd64 (M-A:allowed)
The set of running architectures for perl-script would be empty, since
it consists of the intersection of i386 and amd64 (from the respective
perl modules).
,--> xs-pm-wrapper-a:all --> xs-so-module-b:i386 (M-A:same)
perl-script:all +--> perl-xs-module-b:amd64 (M-A:same)
`--> perl:amd64 (M-A:allowed)
We would ensure that xs-pm-wrapper-a has not M-A:foreign set. The
virtual architectures for xs-pm-wrapper-a would only contain i386. The
running architectures for perl-script would be the intersection of amd64
(from perl-xs-module-b) and i386 (from xs-pm-wrapper-a), i.e. empty.
Barring any mistakes this appears like a possible solution to the
problem. Did you spot anything obviously wrong? Any example where you
don't see how to work it out?
So let's talk about the downsides of this approach. The very big issue
here is that it makes dependency computation way more complex. This is
especially problematic with circular dependencies where I did not
explain how to compute running architectures. Also dpkg can no longer
look at direct dependencies, but has to look at recursive dependencies.
It might be possible to cache virtual architectures as a configuration
step, but it is yet unclear to me how to do that.
This would also significantly weaken the notion of a native architecture
which is heavily used throughout the spec. It also significantly weakens
the architecture requirements for dependencies in general. I have no
clue what else would be broken by this weakening.
Helmut
Reply to: