[Pkg-osg-devel] Plans for OpenSceneGraph 3.4

[Alberto Luaces]

Hi Bas,

thank you for your thorough reply, it is much appreciated.

Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:


[...]

>
> Assuming 3.6 is released before the transition freeze in November you're
> likely to include it in stretch. As long as 3.6 is released before the
> soft freeze on January 5th it can still be included in stretch, but a
> transition to it won't be an option.
>

Ok, thanks for the pointer.

>
>>> If you intend to include OSG 3.4 instead of 3.2 in stretch, we need to
>>> investigate compatibility with 3.4 in its reverse dependencies. If not
>>> we can leave things as they are.
>> 

No, our intention was to have both 3.2 and 3.4 (or 3.6) in stretch from
the beginning.  That is the reason why each version is a different set
of packages, and why there is only version of OT (they are identical, by
the way).

>> 
>> I am certainly interested on aiding osgEarth to be updgraded to newer
>> versions.  Maybe we can test the current developer (OSG-unstable)
>> release 3.5.4.

Yes, our potential candidates would be 3.4, 3.5.4 and 3.6.

>> 
>
> The primary reason we have osgEarth in Debian is for the Globe plugin in
> QGIS, which unfortunately doesn't support osgEarth >= 2.6 in the 2.14
> LTR we have in Debian. QGIS 2.16 does support osgEarth 2.7, and possibly
> supports osgEarth 2.8 too but I haven't tested that yet.
>
> So there is no pressure from our side to get OpenSceneGraph 3.4 or later
> into stretch. I'm perfectly happy to keep osgEarth 2.7 in stretch. QGIS
> 2.16 is probably the last version to support Qt4, although a 2.18
> (non-LTR) release might still happen too, QGIS 3.0 will switch to Qt5
> which the OpenSceneGraph and osgEarth packages also have done for 3.4
> and 2.8 respectively. Those may be better fit for the eventual QGIS 3.x
> LTR which we aim to get into stretch-backports. That eventual QGIS 3.x
> LTR backport could be accompanied by OpenSceneGraph 3.4/3.6 and osgEarth
> 2.8 backports which will all use Qt5.
>
> QGIS and osgEarth are not the only OpenSceneGraph reverse dependencies
> maintained by the Debian GIS team, we also have SFCGAL, OTB and OSSIM.
>
> SFCGAL is not very actively developed, but it's reliance on OSG is
> limited, we can easily drop the OSG support when it's no longer
> compatible with the version in Debian.
>
> OSSIM & OTB only use libopenthreads, which is currently only provided by
> the OSG 3.2 packages. We also have other OSSIM packages in progress
> which do use libopenscenegraph, but these need a lot more work before
> they're in acceptable shape for inclusion in Debian. As long as the
> changes to libopenthreads aren't too disruptive in later versions, I
> don't expect too many issues with those either.
>
> So all in all, I'm happy to keep osgEarth 2.8 in experimental along with
> OpenSceneGraph 3.4/3.6. I'll have to think about moving it to unstable
> when OSG 3.4/3.6 does, for the eventual Qt5 using QGIS 3.x that's
> probably a good idea, although it will break the globe plugin for users
> of the upstream QGIS 2.16 packages. So we may want to stick to OSG 3.2
> and osgEarth 2.7 for stretch after all.
>

I see.  I think that currently the best option is to pass 3.4 to
unstable now, so we will have 3.2+Qt4 and 3.4+Qt5 simultaneously in
stretch.  Therefore you are free to upgrade or not those packages and
decide when to do it, since you will always have 3.2 available at the
bare minimum.

I'd better prefer not to release a developer release (3.5.4) for the
next stable.  The point of moving 3.4 to unstable now instead of 3.6 is
backed up by the fact that we are not certain when 3.6 is going to be
released, and furthermore, there might be big changes in that release:
for example, currently the team is pulling out osgQt as an external
library.  The motivation is aiding us, distro packagers, in the task of
releasing OSG independently of the desired Qt version.

I think I will have it in a couple of days.

Regards,

Alberto