Bug#323747: kdelibs-data: upgrading from 4:3.3.2-6.1 to 4:3.4.2-1 broke kicker & konqueror & more
Adeodato Simó wrote:
> severity 323747 serious thanks
>
> * Alejandro Exojo [Thu, 18 Aug 2005 11:00:25 +0200]:
>
>
>> El Jueves, 18 de Agosto de 2005 09:13, Helen Faulkner escribió:
>>
>>> I upgraded my version of kdelibs-data today, and when I rebooted, I found
>>> that a number of things were broken:
>
>
>> To which version of kdelibs-data you upgraded? Yesterday entered kdelibs
>> 3.4.2, and as Adeodato explained:
>
>
>> http://lists.debian.org/debian-kde/2005/08/msg00089.html
>
>
>> ...you can't upgrade KDE, until all packages depending on kdelibs are
>> recompiled. If you upgraded only kdelibs-data, you had a mixture of KDE 3.4
>> and 3.3.
>
>
> Helen and I talked on IRC, and I asked her to file this bug. While upgrading
> the kdelibs4 package to kdelibs4c2 ensures that incompatible stuff gets
> removed, this is not the case with kdelibs-data. IOW, if upgrading
> kdelibs-data alone causes trouble (and it does), then we have to introduce
> the appropriate package relationships to ensure this does not happen.
>
> On other news, Helen, I just realized this is the same bug as #311958, which
> is solved in sid but not in etch nor sarge. IOW, once kdelibs4c2 is
> installed, it'll always go with an appropriate version of kdelibs-data, but
> KDE versions << 3.4 are still affected. The same fix can't be applied to
> those KDE versions, since it does not constitute a suitable upload for
> testing-proposed-updates, let alone stable-p-u. I guess we're stuck with a
> versioned << conflicts. :/ Oh, oh, wait: Conflicts: kdelibs4 should be
> enough, yay C++ transition!
>
> * * *
>
> Christopher: I just realized that our fix for #311958 leaves the kdelibs
> package in a state in which it can't be binNMUed, which is bad. Since dpkg
> lacks (at least for now) a smart = ${Source-Version} check, I guess we have
> to stick with:
>
> kdelibs4c2 Depends: kdelibs-data (>> 3.X), kdelibs-data (<< 3.X+1)
>
> Or perhaps: kdelibs-data (<< 3.X.50), in case alphas or betas are packaged.
>
> Or we may want to discuss:
>
> Depends: kdelibs-data (>> 3.X.Y), kdelibs-data (<< 3.X.Y+1).
Just to clarify, if anyone is still wondering. I upgraded 4:3.3.2-6.1 to
4:3.4.2-1 by literally running synaptic, updating the apt sources and telling
synaptic to upgrade everything that could be upgraded (I have forgotten the
direct apt-get command for that). I think this would be a fairly common thing
to do and as Adeodato has pointed out, I was allowed to upgrade to the "wrong"
version of kdelibs-data without realising it would cause problems. I suspect
there could be many other people in this situation, if others are in the habit
of assuming that if synaptic lets them upgrade something it will be ok to
upgrade it.
Thanks for replying to quickly to this :)
Helen
Reply to: