Phil Endecott wrote:
One option in theory would be a massive breaks list in the new libc package. I'm not sure howwell tools would handle a breaks list with every package in the archive and there is also the problem that bad packages from unofficial repos may well end up with the same version as good packages from the official repo so a breaks can't be written to hit one and not the other.Hmmm. It's disappointing that apt didn't know about this. Isn't this sort of compatibility between packages exactly the sort of thing that it is supposed to track?
Renaming the libc package would be another way to deal with this but then we'd be stuck with a strange libc package name forever.
Leaving the symlink in place forever would prevent multiarching armel with armhf.
In summary breaking early adopters who used unofficial repositories was probablly the least horrible thing to do.
AIUI the old file/symlink (depending on just how old the version you upgraded from was) was removed due to the fact it was no longer in the package, so further upgrades should not affect your manually created symlink.Anyway, I'm still unsure what I should do now. Presumably I will have to do some sort of apt-get upgrade to replace all packages (or at least all packages with executables). But I think the first thing it will try to do is to replace libc again, and delete /lib/ld-linux.so.3. Maybe I should make the symlink immutable, or something.
The next thing i'd do is continue upgrading the system as normal (apt-get -f install followed by apt-get upgrade followed by apt-get dist-upgrade). From there you have two choices. If you don't care about multiarching with armel you can just leave your system as it is with the symlink in place. If you do care about multiarching with armel you will have to write a script to search for binaries with the old dynamic linker path and then replace those binaries with fixed versions (the exact details of replacement will depend on where you got the binaries from).