Bug#630399: perl: multiarch libc and partial upgrades

[Jonathan Nieder]

Niko Tyni wrote:

> I'd really like to avoid a situation where a perl binNMU may render
> upgrades from squeeze impossible.
>
> The only broken functionality that we're currently aware of
> (ExtUtils::Embed) is actually in perl-modules.

Aside from "perl -V::libpth" itself and the perl build process, the
only code I can find that cares about libpth is the DynaLoader module
(and hence ExtUtils::Embed, etc).

Do you remember why DynaLoader is in perl-base and not perl-modules?

> I think we could bump the perl-modules dependency on perl (and therefore
> transitively perl-base too) and make libc6 break just perl-modules.
[...]
> Does this make sense to you?

If no one is depending implicitly on perl-base to DTRT with respect to
the library path, yes.  That's a big "if", unfortunately.

> On Tue, Jun 21, 2011 at 01:46:32AM -0500, Jonathan Nieder wrote:

>> Ah, here we go.  Based on how Configure computes libpth, what I should
>> have said is gcc-4.6 (>= 4.6.0-12).
>
> Because that would also make sure there's something in
> /usr/lib/x86_64-linux-gnu (or its equivalent on other architectures)
> regardless of which libc6 version is installed?

Make that gcc-4.6 (>= 4.6.0-13).  Reasons:

 1) the package ships files under /usr/lib/<triplet>, as you
    mentioned (and its versioned dependency libgcc1 includes files
    under /lib/<triplet>)

 2) it's recent enough for GCC's own search path to be correct,
    even in mips/mipsel.

I don't know whether (2) is important.  If it's not, a simpler
approach would be to convince Configure to be trusting enough to use
use-provided paths even if the directory does not exist.  That way,
there would be no need for new build-dependencies, aside from dpkg-dev
(>= 1.16.0) for "dpkg-architecture -qDEB_HOST_MULTIARCH".

> Thanks for your help on this,

No problem.  Sorry for all the nonsense.