>> 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