[QGIS-Developer] [Qgis-psc] How to handle upstream Qt fixes

[Greg Troxel]

Nyall Dawson <nyall.dawson at gmail.com> writes:

> 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!!)

I guess then I'm not sure what the question is.  It seems clear:

  qgis source code should build against qt 5.15.2 and also against qtx
  5.15.next (or whatever it's called), and perhaps against some earlier
  qt 5.x

  if something goes wrong that's a qt bug, then probably some reasonable
  effort might be made to accomodate it, but if it's fixed in qtx and
  not in qt-frozen, then perhaps not so much

  maybe qgis would declare that the fork is the preferred source of qt5.

  people who build binaries will choose what they choose.  Maybe there
  would be some sort of "the standard approach is [version-x] for qt"
  guidance statement, and maybe there wouldn't be.

  project-built binaries need to choose

So I'm still not entirely clear what question is on the table

>> 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)

comments on QEP198

  I do not follow how qt 5.15.2 won't work on Apple aarch64.  Presumably
  it can be built on Linux/BSD aarch64, and the apple interfaces at the
  source level remain.  Maybe that's out of date, maybe I'm confused.
  Maybe it is fixed in the fork.

  I don't really see how cleaning up deprecation warnings in 5.15, while
  keeping the codebase entirely ok when built with 5.15, is a break,
  other than from older qt5.  If that's what you mean, that's fine  -
  but if you mean something else, I did not follow.

  It's almost a year later, so I wonder how the build w/o deprecation
  warnings is going.  I think you said there's about 4 FTE-weeks more
  work.

  It would be really nice if the next LTR was dual 5.15/6.  (Sorry, I
  have no spare ponys for you.)

>> 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.

pkgsrc has qt5 5.15.2 currently, and has qt6 packages in our separate
draft repository.  I am not hearing a lot about imminently moving them
to pkgsrc proper.  Overall I get the sense that qt6 has not fully
arrived.  I realize it's been a while formal release of 6.0, but it
seems like enough of a departure that it's difficult.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210908/6da7d5c0/attachment.sig>