Bug#276607: Handling kde upgrades: was: #276607
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.
Reply to: