This is a real mess. However, the breaks relationship was added in response to a cluster of RC bugs after vorlon, rra and I tried to think of a better solution. We thought we had one, although as I went down the path of trying to create a libk5crypto3hat worked with lenny's libdes425 (in lenny's libkrb53),I discovered that if it was even possible, it was more than a weekend's work. So, I fell back to another option that Steve had been trying to convince me was OK: a breaks relationship.
I'd like to understand how bad the Postgres issue is. Is it necessary to have both 8.3 and 8.4 co-configured in order for the upgrade to work?If not, I'd expect aptitude to do a much better job of navigating this mess than apt-get which was used in the blog post. (co-unpacked is OK--co-configured is the problem.) It is almost certainly true that the old binaries will function if they run in the deconfigured state. In my opinion, the root of the problem is that dpkg's replaces handling is never what you want. The problem without breaks is that if you install libk5crypto3, it replaces files in the old libkrb53 (so does say libkrb5-3; libkrb5crypto3 just happens to be what tends to kill you first). Then if you ever uninstall libk5crypto3 you're left without the old files; you don't have a libk5crypto.so.3.0 either from libkrb53 or libk5crypto3. Aptitude thinks this is a reasonable thing to do because lenny packages only depend on libkrb53. All sorts of things break horribly. Arguably when I first packaged libkrb53 back in 2000, I could have split it out. The ABI of all the components had been stable for years, and if we're only feeling pain now, well, we've certainly had less stable things. So, I'd definitely appreciate it if you would be willing to come up to speed on this issue and help us problem solve here. I'm happy to chat via IRC or phone if it would help you understand the problem. Without new inspiration here, we're going to have to pick between ugly messes. If all you can think of is suggestions on how to pick which mess to subject our users to, that would even be a valuable contribution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
