libperl (et al.) packaging plans for stretch
Objectives
- libperl5.xx and libperl5.yy should be coinstallable to keep old reverse dependencies installable later
- benh said in August that linux-tools-* needs this or it will have to drop libperl linkage
- see also #495394
- full standard library (32M) should stay installable for old libperl5.xx embedded interpreters, otherwise they are mostly useless
- this implies versioned packages
- a hard dependency may be fine: almost all systems with libperl5.xx will also have perl installed
- cf. python: libpython3.4 depends on libpython3.4-stdlib (10M)
- note that perl-base will not be versioned, therefore just one perlapi-* is provided at a time
- this means that XS module packages will only be installable for the current version
- offering /usr/bin/perl<version> (dynamically linked to libperl) and /usr/bin/cpan<version> enables users to at least use CPAN to get those modules
- libperl5.xx should (be possible to) become Multi-Arch: same while we're at it
- note that perl-base (and therefore perlapi-*) will not be marked for multiarch before the issues with arch:any - arch:all - arch:any dependency chains are resolved
- this hopefully means that XS module packages will only be installable for the native architecture for now
- offering /usr/bin/perl<version>-<triplet> and /usr/bin/cpan<version>-<triplet> enables users to at least use CPAN to get those modules
- note that marking arch:all libperl-* packages as M-A:foreign may still cause dependency chain breakage; experiments needed
Tradeoffs
- putting arch-indep parts of stdlib into an arch:any package wastes archive space but reduces the number of packages by one (the perl-modules-5.xx package below)
- as above, having libperl5.xx pull in the whole stdlib (options "S" and "M" below) reduces the number of packages but makes libperl5.xx heavier
- this may be a feature, we want the full stdlib to be available to embedded interpreters
- almost all systems with an application embedding a perl interpreter will have the perl package and therefore the full stdlib installed anyway
- this may still look bad when an old linux-tools-* package depends on 34M of "cruft" for people who don't use perl at all
- duplicating essential parts of stdlib (option "S" below) wastes approximately 3M disk space for almost all users but reduces the number of packages by one and makes perl-base more robust by keeping it self contained
- perl doesn't currently pull in the shared library (2M) "unnecessarily" but would start to with options "S" and "M" below
Notes
- the perl-modules package should be easy to drop as it can be Provided by the perl package in the future
- python has opted for a separate -stdlib package, but they don't have the Essential:yes complications we have with perl-base
- the perl-doc, libperl-dev, and perl-debug packages are out of scope for this planning
- perl-debug might turn into libperl5.xx-dbg or something like that
- versioning perl-doc doesn't seem worth the trouble, the docs are on the web anyway
- A preliminary implementation of option "S" below is available in the ntyni/multiarch-5.20 branch of the Alioth perl.git repository. Binary packages are also available in an apt repository,
see the (signed) setup script here.
Current setup
Option S: least packages
Option M: middle ground
Option L: most packages
20150516 /ntyni