Multiarch embedded interpreters pre-BOF, Debconf 2013
15:30 Tue 2013-08-13 In BOF Room2 (downhill from the bar)
Vorlon, Wookey, Doko, Nico Tyni, Helmut Grohne, Johannes Schauer, Raphael Hertzog, Colin Watson, Philip Kaluza, Dom Hargreaves
- Multiarch and interpreters/runtimes
- What shall we do about chains of embedded interpreter and arch-indep, arch-dep, arch-indep modules, which need either some enhancement to the multiarch spec or changing all affected arch-dep modules to arch any.
- How big a problem is this?
See https://lists.debian.org/debian-devel/2013/04/msg00599.html and https://lists.debian.org/debian-devel/2013/04/msg00547.html for background. And proposed fix at https://lists.debian.org/debian-devel/2013/04/msg00599.html
Should apt in Debian assume arch-all _build_-deps as MA:foreign? Or should we fix all the packages
2 basic problems:
embedded interpreter issue: :any->:all-:any
fakeroot (libfakeroot (MA:same), fakeroot (arch:all, MA:foreign) Must match arch of anything run under it.
& nss modules (e.g. libnss-mdns) . This is same issue as fakeroot.
proposed solutions (in order of complexity)
- "make it all multiarch: same, arch:any" (and have multiple versions in archive)
- XS modules have new field "install same architecture as: libperl"
- Calculatin 'running arches' and recording in dpkg state
vorlon: Currently things are not actually broken, as implicit native arch of :all packages means that you won't get a broken system, you just won't be able to install more than one arch of some things (like libperl). The qeustion is how to make this desireable thing possible.
Make relevant :all packages :any instead.
- Archive bloat
- This fixes 1, but not 2
Extra field 'Matches-arch: foo'
- For libfakeroot it would be marked as Matches-arch: libc
- And XS modules marked as Matches-arch: perl-abi-x.xx
- Result "install all arches of package X"
colin: effect on crossbuilding ? (cannot install if a package is not yet built on one arch - e.g fakeroot)
Helmut's "running architectures" proposal: https://wiki.debian.org/Multiarch/InterpreterProposal
- record "running architectures" in dpkg state file
- because of non-locality of dep. resolution
- shellscript requires python and perl, intersection might be empty... what to do ?
- more general solution: define per-dependency arch. annotation
This involves some significant work in dpkg. But gets us not needing to mark all :all packages MA:foreign for free.
Other points 1
Before spending a lot of effort fixing up the spec, we should be prepared to consider whether our original model/assumptions were correct.
- property of the package: co-installable or not co-installable
- property of the edge: needs same architectures / needs any architecture [foreign]
Other points 1
This is helmut's last example, pointing out that none of the solutions are entirely general.
Consider 2 different packages, both of which depend on the same 4 perl modules.
- A) 1 has big script using all 4 modules
uses 2 embedded perl interpreters in different scripts (e.g script that runs exim (which is linked against libperl). 1 uses 2 modules. the other uses the other 2 modules
So the arches of the perl interpreters used by the scripts in B are independent, but the modules in A are not. We cannot express these different dependency requirements currently.
Splitting package B into 2 packages would be one way to deal with this (i.e so one package never depends on 2 different arches)
Some numbers for size of :any->:all->:any issue
http://subdivi.de/~helmut/multiarch_interpreter_workaround.py needs python-apt installed
max of 640 in unstable - many false positives from packages not marked MA:foreign.
Actual likely issues:
ruby 52 mono 159 python 81 (inc python3) perl 178 java 28 node.js 10
- Go away and think about it.
- Determine size of all, any, all prob (done)