Bug#820014: ITP: openscenegraph-3.4 -- Portable, high level graphics toolkit for the development high performance graphics applications.
Hi,
2016-04-05 23:21 Sebastiaan Couwenberg:
On 04/05/2016 10:37 PM, Alberto Luaces wrote:
Sebastiaan Couwenberg writes:
As maintainer of several packages that build depend on
libopen{scenegraph,threads}-dev I'm strongly in favour of a single
openscenegraph source package. Let's just prepare the transition to 3.4
in experimental.
As a maintainer with packages that build-depend on OSG, you shouldn't be
affected by this move, not until there are plans to substitute 3.2 with
3.4 (e.g. renaming the -dev package).
As a maintainer of packages on which OSG build-depends, you can be.
I don't understand what you're trying to say about dropping packages
without warning. Are you concerned that if Debian switches to 3.4 along
with all reverse dependencies, that OSG users will be inconvenienced by
not having 3.2 in Debian any more?
Debian is not only about internal reverse dependencies, users are using
OSG on their own.
In fact, the main motivation for me to maintain OSG (and I am pretty
sure that for the previous maintainer as well, and probably for Alberto
too), is to use directly OSG. I do not even use any of the rdepends at
all, except maybe that I played with flightgear a couple of times long
ago.
So there's definitely an interest in both 3.2 and 3.4 irregardless of
the internal dependencies within Debian.
Dropping reverse dependencies that don't work with 3.4 is an option to
not block the transition for too long, but that shouldn't happen without
warning when properly handling a transition.
AFAIK only Markus Wanner has tested his packages with OSG >= 3.3 and the
results were not encouraging. That just means that his upstreams need to
work on their OSG 3.4 support so we can incorporate those changes in
Debian to keep everything working.
I expect that qgis, osgearth, sfcgal, ossim & otb will all need changes
to support OSG 3.4 too. Once the 3.4 packages are in experimental the
reverse dependencies can be tested and bugs filed.
That's one of the main points of these plans -- to have both for a while
so rdepends migrate at their own pace, and when no rdeps uses 3.2 and
upstream retires support or there are plans to do it soon, remove 3.2.
I think that your OSG-dependent work is not going to be harder —quite
the opposite, since you can choose whichever stable version works or
benefits into your packages, but if that were not the case, I'm of
course open to suggestions.
Because of the interdependencies of the various GIS packages, I don't
want them to use different OSG versions. That is asking for trouble.
The GIS packages will have to migrate to the new OSG version in
lockstep, then.
As long as they don't depend on libopenscenegraph-3.4-dev, everything
should be fine.
OSG is a reverse dependency of GDAL, which requires rebuilds of its
rdeps every new upstream release. Having another OSG version in the
distribution means at least another reasonably big package that needs to
be tested every time including its rdeps that also depend on gdal. The
VTK5/VTK6 unpleasantness was a constant pain in the gdal transitions
too, I'd rather not have OSG take its place now that we're almost rid of
VTK5.
We can keep OSG-3.4 away from testing for a while, if that's what
concerns you about being a rdep of gdal. Packages not in testing are
not a problem for transitions / migrations.
Please talk to the Release Team about your plans to maintain two OSG
branches, if they don't share the concerns I expect them to have there
is nothing stopping your from packaging 3.4 separately. If they do, it
may save you some work on the separate package.
There are tons of packages with multiple APIs/ABIs, starting with the
SDL ones which I maintain, but also guile-1.8/2.0, the kde4/kde5 mess,
or oddities / inconveniences like gcc-4.9 being the still default for
some fringe architectures.
I would very much like to have only to care about one API of the SDL
packages and all its "modules", but this is not possible. Many years
after SDL-v2 being there, and unsupported by upstream since 2012, 75% of
packages still depend on SDL-1.2, there are 300~400 rdepds of
libsdl-1.2.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: