Package: perl Version: 5.12.3-7 Severity: important At some point we need to look at the implications of multiarch changes for squeeze->wheezy partial upgrades.
The libc upgrade that moved libc.so.6, libdl.so.2 and so forth to the multiarch directories broke at least ExtUtils::Embed from perl-modules. See #629670. It's not clear to me if anything else, particularly things in perl-base, were affected. If perl-base is not affected, I suppose libc6 could just declare that it Breaks: perl-modules (<< 5.12.3-7+b1) or something like that (but see below.) If perl-base is affected somehow too, we need to check how the combination Package: perl-base Pre-Depends: libc6 (>= 2.4) Package: libc6 Breaks: perl-base (<= 5.12.3-7+b1) works for upgrades as there's a sort of pre-dependency loop there. I think Breaks: (unlike Conflicts:) should work here but I'm not sure. Unfortunately in practice the (<= 5.12.3-7+b1) part is not quite as simple as that: it looks like not all of the binNMUs were actually built against a multiarch enabled libc (>= 2.13-5 except sparc where it's >= 2.13-7 if I read the changelog correctly.) These problems should show up at some point as FTBFS bugs. At that point (or possibly earlier) we need to reschedule new binNMUs with proper dep-waits. It might make sense to add a './perl.static -Ilib -V' invocation at the end of the build to get an overview in the build log. Manual checks: NOT OK (libc version that perl 5.12.3-7+b1 was built against): ia64 libc6.1_2.13-2 mips libc6_2.13-4 powerpc libc6_2.13-4 s390 libc6_2.13-4 mipsel libc6_2.13-2 sparc libc6_2.13-6 OK amd64 libc6_2.13-6 armel libc6_2.13-5 i386 libc6_2.13-6 kfreebsd-amd64 libc0.1_2.13-6 kfreebsd-i386 libc0.1_2.13-5 Sorry for combining several issues here, I'm not quite sure yet how these are best handled but wanted to document them anyway. -- Niko Tyni [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
