Bug#820014: ITP: openscenegraph-3.4 -- Portable, high level graphics toolkit for the development high performance graphics applications.
Hi Alberto,
On 04/05/2016 10:37 PM, Alberto Luaces wrote:
> Sebastiaan Couwenberg writes:
>>
>> Is packaging 3.4 separately really wise?
>>
>> Having two versions of VTK in the distribution is not very fun, I'm not
>> sure if the Release Team will be more appreciative of two versions of
>> OpenSceneGraph.
>>
>
> Of course maintaining one package is easier than two, but...
>
>>
>> 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.
>>
>
> Currently, upstream *actively* updates 3.2 and 3.4 series. You can
> watch from their downloads page that latest releases (3.2.3 and 3.4.0)
> were released the same day; if you go to upstream's repo at github you
> can see that any patch not changing the ABI is back-ported to both: 3.2
> branch was updated just 5 days ago, the same time as their trunk.
It great that upstream still supports the 3.2 branch, it reduces the
pressure to upgrade to 3.4. Although I can't find the release schedule
for OSG to determine how long 3.2 will be maintained alongside 3.4. Do
you have more information from OSG upstream about their plans for 3.2 & 3.4?
> Many of the questions on the user mailing list are about 3.2 series,so
> it is still widely popular, even if we chose to simply disregard Debian
> packages that currently do not work with 3.4, dropping them without any
> warning.
3.2 has been around for a while and is included in most distributions,
very few have 3.4 already (Gentoo, Arch & MacPorts), so everybody not
building from source themselves is still using 3.2.
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?
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.
> 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.
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.
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.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: