Re: osgEarth 2.5
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
Reply to: