* 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:
> ...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:
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, proposed- updates, let alone stable-p-u. I
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-
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).
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
He has never been known to use a word that might send a reader to the
dictionary.
-- William Faulkner (about Ernest Hemingway)