Hey there, On Wed, Apr 18, 2012 at 02:55:48PM +0100, Colin Watson wrote: > Steve, I think I missed the specifics of what you wanted to do with > libc6-i386/libc6:i386. Would dpkg-divert exiting non-zero have been a > problem here?
Yes, it would. The problem we're trying to solve is that libc6:i386 currently has a Replaces: on libc6-i386 so that it can take over the PI. However, this means that if the user later removes libc6:i386, the PI (now owned by this package) is removed, and packages depending on libc6-i386 now don't work. The proposed solution was for libc6:i386 to apply a divert to /lib/ld-linux.so.2 in its preinst, to preserve any other packages' copies of this file in a different location so that they can be restored on removal. However, libc6:i386 is not always the foreign-arch libc, sometimes it's the transitively-essential one that everything else depends on. So to do this, we *must* be able to tell dpkg-divert "always record the diversion, but move the file IFF it belongs to a different package." This is what we expected from --rename --package, but we hit this bug. So the expected behavior is: - libc6-i386 unpacked, libc6:i386 not yet installed: record diversion, move /lib/ld-linux.so.2 - libc6-i386 not installed, libc6:i386 not yet installed: record diversion, nothing moves - libc6-i386 unpacked, libc6:i386 already installed: record diversion, nothing moves, next upgrade of libc6-i386 redirects to the diverted location - libc6-i386 not installed, libc6:i386 already installed: record diversion, nothing moves On Wed, Apr 18, 2012 at 04:17:30PM +0200, Guillem Jover wrote: > On Wed, 2012-04-18 at 14:42:02 +0200, Guillem Jover wrote: > > I don't think it seems like a good idea to let the caller insert this > > kind of bogus diversion, dpkg itself will try to do the rename on unpack > > which would mess the system up anyway (but I've not though about this long > > enough). So it would seem better at first sight to just abort on --add. > Hmm thinking about it, this does not make much sense. As such diversion > is legitimate and would be equivalent to one w/o --rename, what might be > questionable is the time it gets inserted, so I guess not doing the > rename might be the right thing to do, I'll ponder about it a bit more > after lunch. Right, this should be entirely legitimate. Diverting the PI is an extreme case (and one we've had to work around differently since we can't rely on dpkg in previous releases to handle this), but it illustrates why it's important to be consistent in application of diversions regardless of the installed state of the named package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
