Moving to multiarch-compatible XS paths
On Mon, May 12, 2014 at 04:26:11PM +0300, Niko Tyni wrote:
> 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.
I'd be in favour of this change; it's clear that it will pave the way
for some of the multiarch improvments and if there is still a chance we
will want to target those at jessie, we need to do this now.
We'll need to get policy updated in pretty short order, though.
Could you post a dd-list of the affected packages - it might sway
my opinion slightly (if there are large numbers of non-pkg-perl
packages, for example, we'd need to think more carefully about how we
liaise with maintainers, given the tight timescale.
Cheers,
Dominic.
Reply to: