> On 10 May 2015, at 14:46, Tim Sutton <[email protected]> wrote: > > 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.
My apologies I missed the part about a 2 year transition period from Sebastiaan - which probably negates part of my message above. Regards Tim > > 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Sun, May 10, 2015 at 1:45 PM, Paolo Cavallini <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> 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 >> [email protected] <mailto:[email protected]> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> <http://lists.osgeo.org/mailman/listinfo/qgis-developer> >> >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] <mailto:[email protected]> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> <http://lists.osgeo.org/mailman/listinfo/qgis-developer> > — > > > <KartozaLogo160x66.png> > > > 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 <http://freenode.net/> > Tim is a member of the QGIS Project Steering Committee > > Kartoza is a merger between Linfiniti and Afrispatial > — 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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
