| |||||||||||||
The Grumpy Editor's guide to (some) development distributionsThe Grumpy Editor's guide to (some) development distributionsPosted Nov 8, 2007 15:22 UTC (Thu) by iabervon (subscriber, #722)In reply to: The Grumpy Editor's guide to (some) development distributions by evgeny Parent article: The Grumpy Editor's guide to (some) development distributions
The expat update (and the similarly timed curl update) were, in my opinion, completely botched. The way it's supposed to work is that both versions of expat would be installed at the same time (since they don't have any overlapping files, since the soname of the library changed, which is the fundamental solution for dependancy problems), and the older one could be discarded once you'd rebuilt all the packages that had been built against the old library. Unfortunately, the package maintainer decided to discard the older library at once (since the system isn't set up to discard it automatically when it is safe to do so), which made everything that uses it break in the transition (and revdep-rebuild isn't quite clever enough at package ordering to necessarily fix the broken packages you need to use to build other broken packages first, although it tries). So there is a mechanism in place to avoid this problem, and it's used for a lot of packages, but was not used in this case, which is why there were problems.
(Log in to post comments)
The Grumpy Editor's guide to (some) development distributions Posted Nov 8, 2007 16:18 UTC (Thu) by evgeny (guest, #774) [Link] > So there is a mechanism in place to avoid this problem You're absolutely right, there was a way to handle this specific case gracefully. Still, such a situation (soname change) is impossible in the first place in most "stable" distributions. I could use another example, e.g., once a udev update added a non-standard user to one of /etc/udev/rules.d/*, with a result that my ldap-pam based system hung for several minutes during the boot; etc. In short, when versions of _all_ packages change from time to time, a chance for a, let's say, surprise is obviously higher ;-) One should certainly have this in mind when opting for Gentoo.
The Grumpy Editor's guide to (some) development distributions Posted Nov 8, 2007 17:03 UTC (Thu) by iabervon (subscriber, #722) [Link] An soname change may be impossible in a particular release of a stable distribution, but there have been rather a lot of soname changes in "Debian stable" over the years. Of course, this only happens at a new release, but that tends to make release times especially tricky. This is particularly true because stable distribution upgrades are a rare enough event that the procedures are never sufficiently carefully tested to be a suitable operation to perform on a stable system. The Gentoo mechanism for the stable version is pretty much unique in that you can run a system forever without ever doing anything that's either beyond end-of-life or is outside of the normal update process, whereas other systems require an upgrade, outside of the normal process, eventually. Of course, the actual Gentoo "stable" distribution doesn't necessarily avoid causing occasional breakage, but that's an implementation issue rather than a design issue.
The Grumpy Editor's guide to (some) development distributions Posted Nov 23, 2007 6:22 UTC (Fri) by leio (subscriber, #41189) [Link] It's not that we wanted to give you a world of pain. It was that we wanted to avoid lots of pain that is involved in this specific case when two DIFFERENT ABI version of libexpat are on a system. Library A depends on expat and library B depends on library A and expat - Library A gets rebuilt and will use libexpat.so.1 version, while library B still uses libexpat.so.0. User launches an application linking to Library B, both expat versions are mapped in and providing symbols, things get mixed up between them, enter a world of chaos and random hard to explain crashes caused by the specific case this library works and is used, which made preserve_old_lib method usage not a good option as that leads to exactly that chaos crashy world. We do not have a mechanism in place to avoid that. Manually it was possible to workaround it by making a libexpat.so.0 pointing at libexpat.so.1, because then the same library is used by both library A and B, but in this instance this workaround it worked just for most cases due to the ABI breakage being small. And yes, I am one (out of about three or four) persons responsible for the decision on which route we went with the expat upgrade and I stay by it.
|
|||||||||||||