[Qgis-psc] How to handle upstream Qt fixes

[Nyall Dawson]

On Sat, 4 Sept 2021 at 17:56, Richard Duivenvoorde <rdmailings at duif.net> wrote:
>
> On 9/4/21 8:45 AM, Ludovic Hirlimann wrote:
> > On 9/3/21 00:46, Nyall Dawson wrote:
> >> Hi PSC, devs,
> >>
> >> I'd like to kick start some discussion on how best to handle the
> >> situation with upstream Qt and their (lack of) support for Qt 5. As a
> >> quick summary of the situation:
> >>
> >> - Qt Co effectively ended open source support of Qt 5 at the 5.15.2
> >> release, and have moved all focus to Qt 6.
> >> - While some preliminary work has been done, QGIS doesn't currently
> >> support Qt 6 based builds, and likely won't be ready for this for some
> >> time (even completely ignoring all the stable API questions a Qt 6
> >> build raises entirely!)
> >
> > Wouldn't it be wiser to devote resources to moving to QT6 and do that faster than
> >
> > wait on potential unsuported 5x fixes ?
>
> That was also my thought, though no clue about the amount of work for it.
>
> But my argument against deciding to use a patched/forked qt5 would be that (UNLESS all our development platforms could more or less easily/package/use it), it could potentially break our (little?) "I'm not a core dev, but I compile QGIS myself" group.
>
> My experience (with Linux users at least), is that with some guidance the average Debian/Ubuntu user is able to compile/run QGIS itself, IF all dependencies are taken care of by the distro's.
> When people have to fiddle with LD_LIBRARY paths, my guess is they will break...
> Off course that is 'my bubble', and I'm not even sure about the size of the group, and if they/we are helpful at all etc etc.

I'd never make the KDE fork a requirement for a bulid -- we'd always
have to ensure that users can build using the official releases.
They'd just potentially suffer from upstream Qt bugs which have since
been fixed in the community fork. (And if we do nothing, they'd be in
exactly the same situation!!)

> Maybe it's time for another 'big gap' in QGIS releases? As in: after 3.22 (LTR) there will be a probably not so stable 4.0 which will have a thorough api cleanup (first), while maybe partially trying to do some pre-work for Qt6? And so hopefully we will have Qt6 packaged more easily at that time?

See https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198 for
my proposal on how we handle this. I'd suggest that (when we're ready)
we do a "soft break" and support Qt 6 builds of QGIS 3.x, with the
intention of moving the Windows and Mac builds to Qt 6. We don't allow
ANY api breaks which aren't directly related to making QGIS qt6
compatible, so that plugins will only have to make very minimal
changes (if any)

> What is the Qt6 status in Fedora or Suse?

Fedora has qt 6.1 packages from Fedora 34 (we use these on the CI to
test builds of the core/analysis library on Qt 6). Not sure about SUSE
personally.

Nyall


>
> Glad to see Riverbank at least has PyQt6 already.. (and yes I'm aware Qt now also has bindings itself :-) )
>
> Anyway, thanks Nyall for this forward thinking, but ... hard decisions to make. ...
>
> May the QGIS Force be with us...,
>
> Richard Duivenvoorde
>
> [0] https://tracker.debian.org/pkg/qtbase-opensource-src