[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: