Advertising

On 09/14/2016 04:04 PM, Alberto Luaces wrote:
> [dropping individual addresses and adding our packaging mailing list]
>
> Sebastiaan Couwenberg writes:
>
>> Dear OpenSceneGraph maintainers,
>>
>> What are your plans for OpenSceneGraph 3.4? Do you intend to have it
>> included in stretch alongside OpenSceneGraph 3.2 or instead of or not
>> included in stretch at all?
>>
>
> Our original intent was to release both 3.2 (already present in stable)
> and 3.4.
>
>>
>> The upcoming osgEarth 2.8 release (whose release candidates are
>> available in experimental) has bumped the minimum required OSG version
>> to 3.4 which leaves experimental as the only place to upload the
>> packages as long as OSG 3.4 is not in unstable.
>>
>
> We did not move 3.4 to unstable because 3.6 was announced to be released
> at the end of July, but somehow it has been delayed. We intended to
> package 3.6 in stretch.
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.
>> 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.
>
> 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.
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.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
Pkg-osg-devel mailing list
Pkg-osg-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-osg-devel