Bug#636686: upgrade from squeeze to wheezy fails on i386 (pre-depends loop)
On Fri, Aug 26, 2011 at 02:07:36AM -0700, Steve Langasek wrote:
> retitle 639290 upgrade from squeeze to wheezy fails on i386 (pre-depends loop)
> thanks
>
> Yes, this is a bug in apt, *not* a bug in the dependencies; perl is not
> Essential and never has been, and apt should be able to handle Breaks by
> temporarily deconfiguring the old perl package before unpacking libc6. That
> apt is not handling this indicates a problem in the apt resolver in squeeze.
>
> However, since this bug does exist in the apt in stable, we will need to
> cope with that bug somehow.
>
> But before we start waffling on the implementation, I would like to have a
> reproducible test case - for one thing, I'd like to see if wheezy's apt does
> any better. But I can't reproduce the problem in a clean squeeze i386
> chroot. Adam, can you provide a minimal package list that can be used to
> reproduce the error?
>
>
> For the actual workaround, there are a few options that I see:
>
> - release-note that users must upgrade apt first before running
> dist-upgrade. This is a fairly standard release note requirement, of
> late; it's possible *at present* because apt's dependencies are fairly
> light. If that changes between now and release, this option will not be
> available to us. It also depends on us having an apt in wheezy that
> *can* handle the case (see above).
>
> - revert libc's Breaks: on perl. The original bug report causing this to
> be added suggests that the only known breakage is that using old perl on
> a system with new libc6 to *build* software that embeds perl will fail.
> If that's the case, I think that's not a very strong reason to use a
> Breaks at all since the main functionality of perl remains intact, and
> only one specific use case is broken.
>
> - revert libc's Breaks: on perl on i386 and armhf only. Like the above,
> but retains the protection on archs not affected by the pre-depends loop,
> if we really have to keep it.
>
> - include the ld.so.conf.d multiarch snippets in the multiarch-support
> package, have libc Replaces: multiarch-support to take over these files
> on upgrade, and relax the multiarch-support dependency on i386 and armhf.
> (I haven't tested this solution; Adam proposed it on IRC, and it seems
> plausible.)
>
I don't think this one is a good idea, it means that we rely on the
ld.so.cache for executing system libraries. In case of problem with the
cache, the system is simply broken, at least until ldconfig is ran
manually or if the user tries to reboot the machine to fix the issue.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: