For sid users: An overview of the KDE C++ ABI transition
Hello all,
the purpose of this mail is to explain a bit, from a user point of
view, the upcoming C++ ABI transition for KDE: when will it start, and
how will it affect you. If after reading this you still have doubts,
please bring them up and some member of the KDE packaging team will
try to address them.
* * *
What
~~~~
As a user, you'll just notice that some library packages have been
renamed, and that trying to dist-upgrade them will make apt want to
remove a lot of stuff. For example, libqt3c102-mt will become
libqt3-mt; libarts1, libarts1c2; and kdelibs4, kdelibs4c2.
The explanation as for why is this necessary, and other technical
details, can be found elsewhere if you're curious (e.g., Matthias
Klose's mails in d-d-a).
When
~~~~
Real soon now. We've uploaded a transitioned Qt already, and as
soon as it's compiled in all arches we'll start uploading arts and
kdelibs, and the rest of KDE will follow. If Qt or kdelibs has
trouble compiling with GCC 4.0 in some arches, things could get
delayed a bit, though.
KDE 3.4.2
~~~~~~~~~
As KDE 3.4.2 has been recently released, we've decided that these
transitioned packages we'll be uploading will be 3.4.2 already,
instead of 3.4.1 or 3.3.2. Christopher Martin has been preparing
most of the 3.4.2 modules in SVN, so we're mostly ready. That for
the good news, yay! On the other hand, since there won't be 3.4.2
packages compiled with GCC 3.3, you'll have to actually wait a bit
longer to be able to install the packages (see below), though not as
long as if we were uploading 3.4.1 instead.
Which takes us to...
When will we be done?
~~~~~~~~~~~~~~~~~~~~~
Basically, the thing will be 100% finished when KDE 3.4.2 is ready
to enter testing, which can be roughly translated to "when every
package depending on kdelibs4 has been recompiled to depend on
kdelibs4c2 instead".
Now, please read this paragraph carefully: even when all of KDE
3.4.2 official modulels have been uploaded, there'll still probably
be some applications in unstable that will depend on kdelibs4, and
their maintainers will have to fix that. If you use one of these
applications (and chances are you do), you won't be able to install
KDE 3.4.2 until that application gets recompiled against kdelibs4c2,
unless you decide to temporarily remove it. In the testing
distribution, this is assured not to happen (except exceptionally).
But hey, we don't expect it to be that bad. Most maintainers will
upload fixed packages in a timely manner, and for those who don't,
we will hopefully prepare NMUs to make the transition go faster.
Final recommendations
~~~~~~~~~~~~~~~~~~~~~
In my opinion, the best you can do is to ignore KDE updates in sid
until we get back to you on this list and say, "hey, it seems KDE is
in a mostly useable state now, with these gotchas". To achieve this,
you can either don't dist-upgrade at all, cherry pick with a package
manager like aptitude or synaptic which packages to upgrade, do
"apt-get upgrade" instead of "dist-upgrade", and/or put libarts1 and
kdelibs4 on hold. Or you may even want to consider temporarily
switcthing to Etch (testing).
And, finally: please, please, please, don't file bugs against KDE
packages regarding them being uninstallable, or them crashing, until
the above mentioned mail is sent (the "KDE mostly useable now" one).
Those bugs will be well known by us, are expected in sid, and all
they manage is to waste our time and annoy us a bit.
Greatings from the Debian Qt/KDE Maintainers,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
It is impossible to make anything foolproof because fools are so ingenious.
Reply to: