Bug#630399: perl: multiarch libc and partial upgrades

[Niko Tyni]

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

> > I wonder if there's a danger of an unrelated future change (in either
> > perl or eglibc) bumping the version constraint and causing problems.
> > However, I don't think we should worry about that overmuch at this point.
> 
> Oh.  Yes, that's very likely --- see Bug#625522 (memcpy is attached to
> the new GLIBC_2.14 version node in upstream glibc on amd64). :/
> 
> But I agree, it seems best to cross that bridge when we get there
> (perhaps by asking perl to use memcpy at GLIBC_2.2.5 explicitly on
> amd64).

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. As long as that's the case,
I think we could bump the perl-modules dependency on perl (and therefore
transitively perl-base too) and make libc6 break just perl-modules.

 Package: perl-modules
 Version: 5.12.3-8
 Depends: perl (>= 5.12.3-8)

 Package: perl
 Version: 5.12.3-8
 Depends: perl-base (= 5.12.3-8)

 Package: libc6
 Version: 2.13-x
 Breaks: perl-modules (<< 5.12.3-8)

AFAICS that would give at least this upgrade path:

        unpack new perl-modules
        unpack multiarchified libc
        configure multiarchified libc
        unpack and configure new perl-base
        unpack and configure new perl
        configure new perl-modules

which would keep working even with tighter perl-base pre-dependency
version constraints.

Does this make sense to you?

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

Thanks for your help on this,
-- 
Niko Tyni   ntyni at debian.org