Hi,
(context: Tails Installer currently uses Qt4)
tl;dr:
* Qt4 won't be supported anymore after 2017, so ideally Debian
Stretch should not ship anything that needs it
* Qt4 plugins may be disabled one after the other during the Stretch
dev cycle
* Qt4 webkit will be removed at some point from the Debian archive
(technically, Tails Installer depends on python-qt4 that depends on
libqtwebkit4, but Tails Installer itself doesn't use Qt4 webkit as
far as I know)
=> it's unclear to me if it would be acceptable to upload a Tails
Installer that uses Qt4 to the Debian archive in the next few months.
But what is clear is that the porting to Qt5 or GTK3 has to be done
during the Stretch dev cycle (whose freeze date hasn't been settled
yet, but here's a rough guess: November, 2016), and the earlier the
better, otherwise there are chances that Tails Installer is broken at
any time by this or that removal.
Hi everyone! As you might know Qt4 has been deprecated (in the sense "you
better start to port your code") since Qt5's first release in December 19th
2012. Since that point on Qt4 received only bugfixes. Upstream is about to
release the last point release, 4.8.7. This means that only severe bugs like
security ones will get a chance to get solved.
Moreover upstream recommended keeping Qt4 until 2017. If we get a Debian
release every ±2 years that will make Jessie oldstable in 2017 and deprecated
in 2018. This means we should really consider starting to port code using Qt4
to Qt5 during Stretch's developing life cycle.
It is important to note that Qt4 depends on a number of dependencies that
their maintainers might want to get removed from the archive for similar
reasons. In this case we will simply don't hesitate in removing their support
as long as Qt4 keeps building. This normally doesn't mean API/ABI breakage but
missing plugins that will diminish functionality from your apps, maybe even
key ones. As an example let's take the **hypothetical** case in which the
libasound2 maintainers are switching to a new libasound3 which is not API-
compatible and removing libasound2 in the process. In this case we will have
no choice but to remove the dependency and drop the functionality it provides.
This is another of the important reasons why you should be switching to Qt5.
= Qt4's webkit removal
Webkit is definitely not an easy piece of code to maintain. For starters it
means having a full copy of the code in the archive for both Qt4 and Qt5. Now
add to that the fact that the code evolves quickly and thus having upstream
support even for security bugs will be getting harder and harder. So we
decided to remove Qt4's webkit from the archive. Of course we still have a lot
of KDE stuff using Qt4's webkit, so it won't disappear "soon", but it will at
some point.
Lists of the packages and developers involved will be sent to
debian-devel@??? later.
= Porting
Some of us where involved in various Qt4 to Qt5 migrations [0] and we know for
sure that porting stuff from Qt4 to Qt5 is much much easier and less painful
than it was from Qt3 to Qt4.
We also understand that there is still a lot of software still using Qt4. In
order to ease the transition time we have provided Wheezy backports for Qt5.
Don't forget to take a look at the C++ API changes page [1] whenever you start
porting your application.
[0]
http://pkg-kde.alioth.debian.org/packagingqtstuff.html
[1]
http://doc.qt.io/qt-5/sourcebreaks.html
= Temporarily shipping both Qt4 and Qt5 builds of your library
In case you maintain a library chances are that upstream already provides a
way to build it using Qt5. Please note there is no point in shipping an
application built with both flavours, please use Qt5 whenever possible. This
double compilation should be left only for libraries.
You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries
compiled against one or the other. For example, your source package foo could
provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules
and/or build system accordingly to achieve this.
A good example both for upstream code allowing both styles of compilation and
debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing
how a source can be built against both flavours and another to debian/rules to
see an example of how to handle the compilation. Just bear in mind that you
need to replace $(overridden_command) with the command itself, that variable
substitution comes from internal stuff from our team and you should not be
using it without a very good reason. If in doubt, feel free to ask us on IRC
[2] or on the mailing list [3].
[2] irc.debian.org #debian-kde
[3] debian-kde@???
= Timeline
We plan to start filing wishlist bugs soon. Once we get most of KDE stuff
running with Qt5's webkit we will start raising the severities.
On behalf of the Qt/KDE team,
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
--
intrigeri
