On 02/24/2014 04:29 PM, Francesco P. Lovergine wrote: > Unfortunately, the current goal for Qgis is releasing > three times per year (!) which implies that I seriously doubt > we have any possibility to release a practically useful qgis version > in stable, any time from now. This has been a chronic problem > with qgis for years, but now it has become a certainty. > > The most useful package for that is a roll-on package as provided by > jef in qgis.org under those regards (which is indeed broken from time > to time and not always available for stable). > > I often need to build from scratch using the source package, which > is sub-optimal under any regards. And I do not take in consideration > problems in packaging quality and policy compliance here... > > Myabe, we should consider to release qgis for main architectures only > to reduce problems due to building on exotic platforms (for qgis and its > long list of deps).
Supporting qgis in stable will be a challenge for sure. Not all changes from the upstream release branch will be acceptable for stable proposed updates. But cherry picking selected fixes should be doable. Debian stable user whose needs are not met with the qgis package in Debian have the option to get a more recent version from upstream repo. While I'm not a fan of 3rd party APT repositories, it already provides backports without having to go through testing migrations solving addressing many users needs. An approach like mozilla.debian.net with a DD maintained backports repository would be also a good fit for a fast moving package like qgis I think. But the benefit over the upstream maintained APT repo is low, it's just nice to have the unofficial packages from the same maintainer as in Debian proper. Most people I know don't actually use the qgis package from Debian, they all use Ubuntu with qgis from the UbuntuGIS PPA, so they use the upstream packaging anyway. I'm very pleased that I can apt-get install a recent version of qgis again without requiring sources.list modifications. That's what I expect from a Debian system. Most software you can think of is already packaged, and even for exotic architectures. I'd like to keep supporting the exotic architectures as long as possible, but when this becomes too burdensome I'm not likely to object to limiting the supported architectures. Once OpenSceneGraph is fixed on hurd-i386, osgEarth will likely FTBFS because the pthread fallback is insufficient there. It will likely require a Hurd specific systemcall to get the thread ID. And once we've fixed osgEarth I suspect Murphy will have a nice Hurd FTBFS of qgis for us too. I had opted to make osgEarth linux-any because of the thread ID problem on kFreeBSD and no upstream support for FreeBSd in general, but in the fix was not very hard with some help from the porters. So considering limiting the supported architectures is a good thing to think about, but I also think we should try to support them all also long as possible. With the current Debian and QGIS release planning, we should be able to get QGIS 2.4 into testing. The five months between its release on 2014-06-20 and the Debian freeze in November should be sufficient. The planned release of QGIS 2.6 on 2014-10-24 is most probably too late, but we can choose to maintain it in experimental for those of us running sid or focus on backporting 2.6 changes to 2.4. Kind Regards, Bas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
