Skip to content

Qt 5 Dependency on Linux

Jump to bottom
Olivier Goffart edited this page Apr 28, 2015 · 3 revisions

After having found a fix for bug #2425 we're in the situation that we need a patch on top of Qt to get this serious issue fixed for the users.

The problem is that the list of distributions that we want to support mostly still ship Qt4 in the default installation, see #2558. And even if they ship Qt5, they do not have the patch that is needed to fix #2425

This issue is to discuss the pros and cons of the possible solutions for this problem. Note that we have this problem only on Linux. On Windows and Mac, we build and ship our own Qt anyway. For Linux we try to be good citizens in terms of packages but that becomes hard slowly.

Please stand away from all forms of +1s here.

Possible solutions:

  1. Ship a private Qt version Put all the Qt libraries and their dependency in the package and install everythin in /opt/owncloud/lib, including libpng, libstdcpp, ... We don't necessarily have to compile everything ourselfs, we can just copy the binaries from one distro

    Pros:

    • Fully flexible in what we ship
    • We can rely on better building tools (newer cmake, compiler)
    • We just have to maintain only one linux build
    • We could have an auto-update working (if we install everything in $HOME/.owncloud )

    Cons:

    • Bigger downloads (How big exactly?)
    • OBS challenges
    • We need to monitor security issues that might impact us in all the dependencies. And we would not benefit from the security updates of that library from the distro if this happen. (e.g. if openssl has a security issue, then the user would get a new release of openssl from the distro, but they would also still need to download an updated owncloud)
    • No integration with sytem Qt plugins (KDE platform plugins / themes)

This of course would only impact the users of the binary package we ship. The owncloud client would still available in the distribution repository upstream as a normal distro package. Only users who wants a newer package that what the distribution offer would be affected (and they could still build themself from sources if they really want it clean on their system), or the branded client.

  1. Provide updated, non private packages for all the distros

    Pros:

    • Fully flexible in what we ship

    Cons:

    • OBS challenges
    • We need to maintain Qt packages on our own for every distributions
    • Some ditributions might even require additional dependencies that we would also need to maintain

  2. Static linking Static linking proper is not really possible anymore with modern glibc anyway. And it is also much more work because we would have to rebuild the world.

  3. Rely on distributions: Provide them with the patch, ask them to update their packages and drop support for old distros

    Pros:

    • No need to maintain Qt package ourselfes

    Cons:

    • Slow, unreliable. May not even happen.
    • We need to maintain Qt4 build
    • We cannot use the recent Qt features (Increased development burden)
    • We still to maintain the old neon stack if we want bandwith limiting.

☁️

Clone this wiki locally