Hi

What about considering alternative packaging methods? For example making an 
equivalent of the windows standalone package for Linux.  A long time ago I used 
to build QGIS and all its dependencies into a directory (e.g. /opt/qgis2.8)  
and then use a launcher script to update the library paths to each in that dir 
with priority over the system libs. The result is something pretty portable and 
self contained. There are free NSIS like tools for Linux and we would no longer 
be reliant on which libraries are available on the host system. 

More recently we achieved similar results with Docker (e.g. 
https://registry.hub.docker.com/u/kartoza/qgis-desktop/ 
<https://registry.hub.docker.com/u/kartoza/qgis-desktop/>) 

I appreciate that there are many good reasons to use shared libraries on an 
operating system, but there are also many good reasons not to:

* cross distribution binaries
* ability to install multiple concurrent versions of QGIS and know they will 
work (e.g. we recently had pain when software we wrote depended on QGIS 2.2 but 
was no longer installable from debian archives)
* we could provide all the extra goodies that give you a good experience and 
that are hard to get configured on each distort (grass, saga, OTB, goal with 
lots of drivers)

IIRC gdal used to follow this route in the past, and other non FOSS packages 
like Google Earth etc do too.

In our PSC thread referred to by Anita below, it became apparent that a lot of 
people will have a hard time if we jump to Qt5 & Python 3 as a requirement, so 
we should look for approaches (such, as but not necessarily,  the one above) 
that provide use some level of independence from the underlying OS and its 
provisioned packages.

Also much as I love debian, lets keep some perspective, it is probably a very 
small part of our established user base (the bulk being on Windows) and it 
does’t make sense to me to make the majority of users unhappy to keep the 
minority happy.

In our road map for migration from QGIS 2.x to 3.x we should definitely plan on 
supporting 2.x for an extended period in order to allow users and developers to 
migrate their work to the new platform. so any approach which implies a hard 
cut off of 2.x support would be suboptimal in my opinion.

Last thought: I wonder if debian plans on supporting the new snappy package 
format from Ubuntu which I believe will be used for desktop packages too from 
15.10 (in addition to deb packages).

Regards

Tim


> On 10 May 2015, at 14:16, Anita Graser <anitagra...@gmx.at> wrote:
> 
> On Sun, May 10, 2015 at 1:45 PM, Paolo Cavallini <cavall...@faunalia.it 
> <mailto:cavall...@faunalia.it>> wrote:
> Seems a rather serious issue. Shouldn't we reconsider our roadmap accordingly?
> 
> ​I don't seem to be able to find any dates mentioned in the linked resources. 
> When (date) will Debian remove Qt4? 
> 
> This basically warms up our discussion on 
> http://lists.osgeo.org/pipermail/qgis-psc/2015-April/002974.html 
> <http://lists.osgeo.org/pipermail/qgis-psc/2015-April/002974.html>
> 
> Best wishes,
> Anita
> 
> 
> 
> 
>  
> All the best.
> 
> Il 10 maggio 2015 11:25:23 CEST, Sebastiaan Couwenberg <sebas...@xs4all.nl 
> <mailto:sebas...@xs4all.nl>> ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 05/10/2015 10:51 AM, Matthias Kuhn wrote:
>  Hi
>  
>  On 05/09/2015 03:28 PM, Paolo Cavallini wrote:
>  Il 09/05/2015 12:38, Sebastiaan Couwenberg ha scritto:
>  
>  How feasible is switching to Python 3?
>  I believe this would be a huge issue: most or all plugins will
>  not work, both the internal and the external ones, so our qgis
>  will be badly lame. Thanks for raising this point.
>  
>  There will probably be no PyQt4/Qt5 package but only a PyQt5/Qt5
>  package? If there's a
> PyQt4/Qt5 package the upgrade process should
>  be rather painless. If there's none, all plugins will need an
>  update anyway and IMO the two changes PyQt5 and Python 3 should be
>  grouped. Sebastiaan, do you know anything about this package?
> 
> I'm not involved in the Python or PyQt packaging, so I have no
> intimate knowledges of those packages.
> 
> Both the python-qt4 [1] and pyqt5 [2] packages in Debian have the same
> people involved. They may be willing to provide a python-qt4 package
> built with qt5.
> 
> [1] https://tracker.debian.org/pkg/python-qt4 
> <https://tracker.debian.org/pkg/python-qt4>
> [2] https://tracker.debian.org/pkg/pyqt5 
> <https://tracker.debian.org/pkg/pyqt5>
> 
>  The other issue is that there's a rather big dependency on
>  QtWebkit currently. We are
> struggling already with that on
>  Android. Alternatives * QtWebEngine is the future but only
>  available starting from Qt 5.4. So this is not an option now. *
>  QLabel/QML: Where it's only used for richtext, a QLabel can be
>  used. Where there's javascript involved it may be worth
>  investigating the use of QML.
> 
> The planned removal of the Qt4 WebKit component in Debian is the
> primary reason to switch to Qt5. Sticking to the Qt5 Webkit until Qt
> 5.4 is widely available seems like the road of least resistance.
> 
> Kind Regards,
> 
> Bas
> 
> - -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCgAGBQJVTyQDAAoJEGdQ8QrojUrxg6kP/Aj8sSsq6eOSG5EKQbbzG2YP
> xazhDxSbrPJGKql2LaPDOwMb5ChlkTQUi13SZi9Y3B6iUU0IQ11B8zvsTDz+qUC5
> t3srte+XyJDCDky7gLhRWIikm92F3lusfyrk0t3MCDVdetvt15k3kEUH2M7Nt3jD
> t1FzhypFVbxLSR7S1a7oM+fy9wp3Z301yYwnpAj8OdhCPL9XM9BxHg2g88hydYMC
> L/4KdWO3i82HTUsAO1iG6CtY+oYc0a9EL0pelRtcV+icvDycgID1+As/PZrgA3sN
> 990HWsT4PUgeO2dISte5NtQcLzZw3GrKDiwU3VCU2Zaa2JZWYbKmbHtLWPQIgjMD
> Tf6hw9QJORIVP58m1I9loF+fT0emBp5fe6FcoIiSAKfLNEVYNJRRMz7y/4Nm4T9p
> ALnwgSvJQdNpPx5KluPOg4QecCCkmWj8xQ7IpuFVcpxLMrINGKRokzamL5mzHFFW
> fSkO/zE6lYWeXX8SiT/suavpWi1hQOxqXGRLy0KBeNRSqGywVDQAqxzt3+LWKwZs
> 8cAv9ySdQqmx2GLOUIzkl8g/zfwudI9WN1/n/oLl2GZ5GIGS9yZgka+N1VrFvAb3
> gcd3hQxyMxnYBvJ98eLEUlHuNgp9Y74QX4Ap6i8ss53WtTQG+dcBFjrJDFvaU2GO
> QzV9i13DJiKUdDj6/Lx8
> =3Ioh
> -----END PGP SIGNATURE-----
> 
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 
> -- 
> http://faunalia.eu <http://faunalia.eu/>/
> Sent from mobile, sorry for being short
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/qgis-developer 
> <http://lists.osgeo.org/mailman/listinfo/qgis-developer>
—





Tim Sutton

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to