Plans for 5.20

[Niko Tyni]

On Sun, May 11, 2014 at 11:40:51AM +0300, Niko Tyni wrote:

> After thinking it over, I think now would be a good time to move
> /usr/lib/perl5 and /usr/lib/perl/<VERSION> to the multiarch paths
> (/usr/lib/<triplet>/perl5 and /usr/lib/<triplet>/perl/<VERSION>. 
> 
> This is a necessary precondition for future Multi-Arch:same packages but
> can be done in advance. It's easiest to do with an ABI change, when all
> the XS modules need to be rebuilt anyway.
> 
> Packages should generally do the right thing, as long as they use
> $Config{archlib} and $Config{vendorarch}, which well behaved packages do.
> Still, this needs a Perl policy change.

> I suppose the next step should be some test rebuilds to get an idea of
> the fallout. Ideally  one set of rebuilds with the multiarch commits
> and one without them.

Here are my results from rebuilding the relevant packages (the ones that
would need a binNMU anyway) on amd64 with 5.19.11 and the multiarch
path changes. I manually inspected and classified the failures instead
of doing two rebuild sets.

537 total source packages to be built
410 built successfully
 10   of those built successfully but were visibly broken:
  2    of which lost libperl linkage due to the multiarch path changes
  8    of which still installed in /usr/lib/perl5 despite the multiarch changes
127 failed to build
  7   of those fail to build on current sid too
  2   of those failed to build due to local problems (disk space issues) 
 13   of those failed to build (probably) due to other 5.19 changes
 56   of those failed to build due to the multiarch path changes
 49   of those failed to build due to missing dependencies (other failed builds)

So the change breaks (at least) 66 packages. Almost all the problems look
like trivial packaging issues hardcoding usr/lib/perl5 in debian/rules
or debian/*.install.

Additionally, there's a handful of packages that install into
/usr/lib/perl5 but don't have a hard dependency on the perl version,
so they'd need to be rebuilt and the old versions Broken by the new
perl-base.

Dominic, any opinion? The fallout doesn't seem *too* bad, we've seen
much worse in some earlier transitions. However, as the Perl policy
is currently hardcoding /usr/lib/perl5, those 66 packages are arguably
currently not buggy at all.

Possibly we need a transition period where policy recommends using
$Config{vendorarch} but its value stays at /usr/lib/perl5. That would
mean postponing the actual change until after jessie (5.22 or whatever).
Personally I'd prefer to do the change right away.

This probably merits a discussion on debian-devel / debian-perl.
-- 
Niko