>> How do you plan to package it? With the system QT (i.e. a lot of features
>> will be disabled) or with the patched QT? FreeBSD has packaged it [1] with
>> the patched QT, but I know that Debian has a policy which may apply in this
>> scenario [2]. Without the patched QT, a lot of the additional functionality
>> is disabled.
> It will be packaged with the system QT in order to respect the Debian Policy.
>
Sorry for the rather long reply, but wanted to put things in
perspective for the reason we need the patched QT.
wkhtmltopdf was initially authored by Jakob Truelsen, who tried to
upstream a lot of the patches to QtWebkit that we are using. There was
not much interest upstream (and there were effectively two upstreams:
QT and WebKit). After QT 4.8, the focus of the QT team shifted to QT5
and QT4 has been in "maintenance mode" for quite a bit of time. I did
consider a migration to QT5 and then trying to upstream the patches
there, but then I found that QT is switching to Blink [1]. The current
QT port also has been removed from the Webkit upstream [2]. There is
no plan of the QT team to enhance QtWebkit -- please see the comments
in the "What does all of this mean for users of Qt WebKit?" section in
[1]:
After the release of Qt 5.2, we will focus most of our new
development efforts on the new Qt Web Engine [...] While we no longer
will do any feature development in Qt WebKit, the existing version
will continue to be available.
So the patches are unlikely to be accepted by either Webkit or QT. The
QT WebEngine has released a preview 2 weeks ago [3], so switching to
that is an option -- but that is something for the future. I do not
think that it will be packaged and available in testing for at least
1-2 years, so it is unlikely to be an option for 2 debian releases.
The only option facing us in such a scenario is to fork the codebase
and incorporate the patches, and decide upon what to switch to later
on. This is not a scenario unique for us -- phantomjs also has the
same problem, and they too have incorporated the QT source in their
repository for the same reason and historically there has been a
cross-polination of patches/features between the two projects.
We are willing to try to get things upstreamed (we maintain a series
of patches for that very reason) but when upstream is not interested,
there is a need to fork. I am willing to work with the Debian QT
maintainers to incorporate the patches in the debian version, but I
doubt they would be interested -- it's not going to be easy to ensure
that there are no regressions (this was rejected by the Fedora QT
maintainers as well [4]). As a number of features [4] depend upon the
patched QT, people have to consistently use static builds to get it to
work for their need -- which is not a good idea when the package is
present in Debian!
Regards,
Ashish
[1] http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/
[2] https://lists.webkit.org/pipermail/webkit-qt/2013-October/003878.html
[3]
http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/
[4] https://bugzilla.redhat.com/show_bug.cgi?id=955996#c3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
