Re: Removing qgis from Debian
On 06/28/2016 01:54 PM, Francesco P. Lovergine wrote:
> Let me remember that I privately (maybe, but I had not problem in reporting in
> public) clarified that supporting Qgis in
> Debian main archive is quite pointless. That's due to the fast release cycle,
> which renders uninteresting for users any qgis release already during the testing
> freezing phase, and surely obsolete at stable release time.
That's why there are backports for the LTR now.
> I use to install the qgis.org packages for stable and unstable
directly, and thanks
> upstream folks and jef specifically for providing that service for users.
>
> It is a reasonable tradeoff which could be occasionally subject to problems with
> dependencies in sid, but it is preferrable to having a permanently obsolete
> package or a broken program for a large part of the Debian release cycle.
The problem with QGIS is not the fast release cycle, the problem is the
too slow response to changes in its dependencies. We've seen that with
GRASS 7 before, and now with osgEarth 2.7 and QtWebKit. This saddens me
greatly for such a well-funded project.
For the sake of our users, to not force them to rely on the upstream
packages, I won't push for removal of qgis from Debian just yet. Based
on Richards feedback (many thanks for that!), I'll stick to 2.14 for the
time being, so we'll adopt next weeks 2.14.4 release instead of
switching to 2.16.0. Having both LTR and non-LTR in Debian (like Firefox
and its ESR for example) would be great, but the burden of having to
support both is just too high.
With the current release planning we should be able to get 2.14.10 into
stretch (the last release before the soft freeze on January 5th).
Hopefully that gets most of the QtWebKit issues in QGIS core (not
plugins) resolved. We can have the subsequent 2.14 releases in unstable
for syncing into Ubuntu, and possibly into backports to bridge the cap
until the next LTR. I don't expect the stretch release before the last
2.14 LTR, so for the stretch lifetime the 3.x LTRs are the most likely
candidates for backports.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: