[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removing qgis from Debian

On 26-06-16 05:33, Jürgen E. Fischer wrote:
> I never indended to release packages for Qt5 before QGIS3 - and we also want to
> couple the migration to Qt5 with Py3/PyQt5 - because we have to consider the
> plugins and not only QGIS itself.
> And we didn't plan to backport the preparation for QGIS3 to earlier versions
> either.  We'll stick with Qt4/Py2/PyQt4 for 2.x packages.
> And as there is no webkit replacement for Qt4 in Debian, we've disabled what
> depends on webkit where it's not available.  So the packages on
> testing/unstable miss some functionality (namely full featured maptips,
> embedded webview in forms, feature info in identify results and some pages in
> the about box), some stuff was ported to QTextBrowser (processing help, plugin
> info in plugin manager), but the vast majority of stuff is not affected by this
> at all.
> Same with the globe core plugin - it's available where the required osEarth
> version is available (ie. <=2.14 has globe where osEarth <2.7 is available,
>> 2.14 will only have globe where 2.7 is available).  But not having the
> globe plugin available everywhere IMHO isn't a huge problem either.
> Of course not ideal, but the preferable tradeoff compared to a Qt5 QGIS without
> plugins.  Still plugin authors have to deal with the fact that their plugins
> cease to work on Debian testing/unstable if they depend on webkit (eg. the
> openlayers plugin).  But that's somewhat like any other python module - that
> might or might not available.  Not sure how important they'll consider stretch.
> And by the time stretch releases we might already have 3.0 - without the
> temporary webkit problems.  But of course that's far too late for stretch.

I (professionally) use Debian testing with QGIS master (self compiled,
based on vanilla Debian, without community repo).

I think the QGIS project handles the Qt4 removal good enough: QGIS
misses some functionality (not used by me personally), and notably some
plugins, but for most there is a way around it.

Instead of OpenLayers plugin for example, one can use the
QuickMapServices plugin!

osEarth I do not use to be honest.

But my take to Bas: please keep packaging LTR/2.14 even it misses some
functions. I think 2.14 is currently the best choice.

And 2.16 would be ok too if users prefer that as an upgrade, but if
packaging (in combi with osEarth) is a problem: let's just wait for 3.0
for the next packaging upgrade.

QGIS 2.16/Qt5 builds are too experimental.

AFTER 2.16 there will be a full focus on Qt5/Python3.

2.14 'just works' 99% of the functions. The OpenLayers issue is actually
a plugin issue and only for Debian testing users and out of the projects
responsibility. We have sometimes too many masters to serve :-(

And also from my side: a big thanks for all the work you do and have
done for FOSS GIS and QGIS and Debian!


Richard Duivenvoorde

Reply to: