On Fri, Oct 15, 2004 at 03:51:51AM +0200, Adeodato Simó wrote: > $ dpkg -x libmimelib1_3.2.3-1_i386.deb before > $ dpkg -x libmimelib1_3.3.0-1_i386.deb after > $ objdump -TC before/usr/lib/libmimelib.so.1.0.1 | grep > AllFieldBodiesAsString > 0001cf60 g DF .text 000000be Base > DwHeaders::AllFieldBodiesAsString(DwString const&) > > $ objdump -TC after/usr/lib/libmimelib.so.1.0.1 | grep > AllFieldBodiesAsString > $ > this obviously leads to broken installations if one upgrades mimelib > without upgrading, e.g., kmail.
It's an upstream issue. SONAME should be changed on each incompatible change. However, as it appears that kde isn't going to respect that... > this would be achieved via conflicts or similar methods, and of course > only for binary packages from a same source package. for example, one > could have the "kdepim-base" (empty) packge on which all kdepim binary > packages would depend on (with = X.Y.Z-d, and "kdepim-base" itself > would conflict all other kdepim packages << X.Y.Z *and* >> X.Y.Z. > if the above is regarded as to cause more grief than it would solve, > reconsider after s/X.Y.Z/X.Y/ in the last line of the above paragraph. At kde maintainanence, we have traditionally avoided using versioned conflicts, as the apt maintainer is claiming that they should only used in extreme cases, and that kde's current wide use of versioned conflicts is making (for example) apt-get dist-upgrade from woody to sarge (see #183702 and #183985 for example). However, we may need to make our package interdepencies more strict. Every time any new kde packages are uploaded to sid or migrate to sarge, we get a bunch of "Unresolved symbol Z4FooBar" or "I dist-upgraded and nothing works anymore" bug reports. After all of the kde upload bunch is migrated, the problems disappear, which ofcourse is sign that our depencies are not strict enough. However, is just enforcing same version within the source package isn't enough? For example, as far as I can know, in kde some symbol could be dropped in kdelibs 3.4, and if kdepim uses that symbol, it won't work anymore after the new kdelibs is installed. To properly enforce it, we would need a more brutal approach: Package: kde-version Version: 3.3.0 Conflicts: kdelibs4 ( << 3.2.99 ), kdelibs4 ( >> 3.3.0.99 ) Package: kdelibs4 Version: 3.2.3-3 Depends: kde-version ( = 3.2.3 ) Package: kdelibs4 Version: 3.3.0-1 Depends: kde-version ( = 3.3.0 ) Now, since most kde packages depend on kdelibs4, we don't need to explictly conflict with all kde packagess. However, the change would make life for sid users a real pain in the ass. Instead of kde being _unusable_ when a new kdelibs->kdebase->kdepim etc chain is in progress of being uploaded (ie most of the time), kde would be _uninstallable_. So the bug reports would be "Can't install kde in sid" and "Apt-get dist-upgrade is holding kde packages" instead of the ones in the earlier paragraph. Your idea (per-source base packages) improves the situation, for some reason especially kmail users seem to mix different versions of the supporting libraries provided by kmail, and end up with a broken kmail. I'm not sure what would be the proper way to solve all cases, as symbols seem to appear and disappear even between minor releases.