On Monday 20 April 2015 13:28:59 Lisandro Damián Nicanor Pérez Meyer wrote: > Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to > the problem that QtWebEngine poses for us distros (in this case, at least > Debian and Fedora). > > I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a > hard (very hard) piece of software to package. > > It embeds quite a lot of 3rd party stuff which we distros don't accept (in > different grades depending on the distro) as we require to build using the > system versions. Fedora's Rex Dieter tells me that's actually why chromium > is not available for them. > > Moreover we can't build debugging symbols on most archs due to the enormous > amount of RAM+swap it involves in the linking process (more than 8GB last > time I checked). This is at least the same as QtWebKit, but seems to be > getting worse. > > Yes, we do understand that QtWebEngine is technically superior to any other > thing out there but making that code an acceptable package is another thing. > > So basically what I'm trying to say is: don't expect us down streamers to > easily package QtWebEngine soon, if we ever get to it. > > I'm really sorry if this comes as "bad news", but the reality is currently > this :(
Have you notified the Qt WebEngine developers about this? I have not seen any email in that regard to the official upstream mailing list at qtwebengine@qt- project.org . Previously, many of the 3rd party stuff was just hardcoded and shipped internally because it was easier to get stuff done. Now with things settling a bit, afaik one could start working on the build system to use a system- provided version of "the 3rd party stuff". Some stuff will probably always be shipped internally, but at least this could help things a bit. In all cases, its sadly sometimes simply not possible to make different FOSS code work together without custom patches for a certain project. Yes, this is against the ideal utopia we all dream of, but with limited man power there will always be problems like this. Regarding debug symbols, it certainly works with ld as others have mentioned. And it is definitely easier to build than QtWebKit. Anyhow, I won't judge distros when they won't package software that is against their principals. But I hope you guys also understand that for some developers a good solution for some people is better than a half baked broken solution for some more people. I'm not a KDE PIM maintainer, but with my KDevelop hat on (that uses a web view to display documentation pages, currently QtWebKit), I could understand a projects decision to just make a certain feature optional. Certainly less maintenance effort than supporting different implementations. Bye -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
