Bug#630399: perl: multiarch libc and partial upgrades
Niko Tyni
ntyni at debian.org
Mon Jun 13 18:02:22 UTC 2011
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 ntyni at debian.org
More information about the Perl-maintainers
mailing list