[osg-users] osgQt versioning problem

[Jan Ciger]

On Fri, Jun 12, 2015 at 1:00 AM, Jannik Heller <scrawl at baseoftrash.de> wrote:
> Hi Jan,
>
>
>> The only way you could have problems is if you rely on the OSG
>> libraries shipped by the distro, where you don't have control over how
>> it was compiled.
>
>
> That is precisely what's going to happen. My application is likely to become available in distro repositories (FWIW, an older version of my application that isn't using the OSG *is* already in distro repositories). Packaging guidelines typically require a package to use the established library stack. A package isn't likely to get accepted if it ships its own forks of already packaged software. That would be a maintenance and security nightmare.

Then it cannot be a problem, because all distros recompile the
applications they package for their repositories using their
libraries. You can specify in the spec file (if you are building for
RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...)
which library version your application needs. Then the package will
not build for the repository maintainer until the requirements are
met.

The only exception are binary-only, proprietary software packages -
but there you are on your own and shipping everything needed is your
problem.

> Sounds easy in principle, but will cause a waterfall of problems for package repositories.

I don't see how - if you set up your package requirements properly,
then there is no way the repository maintainer could build your
package requiring one version of Qt and build OSG using another one.

>
> - Not all application developers are willing or able to upgrade to Qt5 yet.
> - *if* there is a mismatch, we just get a crash, instead of the mismatch being detected at the build system stage. The packager or tester is left to dig into the crash to find out what's wrong. There is no way for the application to detect what version of Qt the osgQt was built with, so the application can't provide a sensible error message either. Ultimately, the developer will be left to deal with lots of support requests by frustrated users.
> - If one package requires osgQt5, but a different one requires osgQt4, we get a conflict. The user wouldn't be able to install those two packages at the same time.

Well, there isn't really a way around that - you must have two
versions of OSG installed side by side for this to work. That's the
responsibility of the distro packager, IMHO, not yours. If they build
the packages inconsistently, despite your specified requirements,
well, things won't work, but only they are to blame in such case.

OSG is no way special there - this is a common issue with software
requiring e.g. specific version of Python, wxWindows toolkit,
KDE/Gnome ...

>> In addition, if you are trying to distribute a binary-only package
>
> I don't. I just distribute source-code and let others worry about the rest ;)

OK. I would say that the only thing you could do is to document this
requirement. It is the packagers' job to deal with this.

> My suggestion is:
>
> - Provide separate libosgQt4/5 libraries.
> - Provide a libosgQt library that points to the default, either 4 or 5, for backwards compatibility.
> - Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, allowing applications to opt for a specific version.

You just have to build OSG twice using each version of Qt in turn. OSG
respects the DESIRED_QT_VERSION already.

cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series

Regards,

J.