Bug#630399: perl: multiarch libc and partial upgrades

[Niko Tyni]

On Tue, Jun 21, 2011 at 10:03:29AM -0500, Jonathan Nieder wrote:
> 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?

It's used to load all XS extensions like POSIX.so, Socket.so and so forth.
However, I can't see why that functionality would need anything from
libpth.  This needs to be checked properly of course.

ExtUtils::Embed doesn't use DynaLoader, it needs libpth (via
ExtUtils::Liblist and ExtUtils::Liblist::Kid, both in perl-modules)
because its job is to be the canonical source of linker and compiler
arguments when embedding perl and it wants to check that all the libraries
can be found in the process.

> > I think we could bump the perl-modules dependency on perl (and therefore
> > transitively perl-base too) and make libc6 break just perl-modules.

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

I'm not quite that pessimistic about this. It would seem possible to start
by just breaking perl-modules and only change that later if necessary.

> > 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).

> 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>)

Great, that's what I was missing.

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

Do I understand this correctly: it's possible that a multiarch enabled
libc can be present with a non-multiarch aware gcc, particularly on mips?
Doesn't that break just about all compilation functionality?

> 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".

(2) might be important for getting the h2ph path right. This is related
to #625808: the pending fix is to parse the #include search path from
'gcc -v -E - </dev/null'.

Anyway, if the GCC search path isn't correct, the perl build should
fail when the generated .ph files are checked, so there's no chance of
ending up with a crippled build or anything like that. If this is/was
just a transient problem in sid, I don't think we need to specify build
dependencies to avoid it.

Aside from that, I agree that changing Configure is starting to look
like the cleanest solution.
-- 
Niko Tyni   ntyni at debian.org