KDE Gear 24.12.0 packages available for packagers

[Albert Astals Cid]

El diumenge, 8 de desembre del 2024, a les 11:32:34 (Hora estàndard del Centre 
d’Europa), Tobias Leupold va escriure:
> E-Mail von Albert Astals Cid vom Sonntag, 8. Dezember 2024, 11:19:21 MEZ:
> > El divendres, 6 de desembre del 2024, a les 13:58:01 (Hora estàndard del
> > 
> > Centre d’Europa), Tobias Leupold va escriure:
> > > E-Mail von Heiko Becker vom Freitag, 6. Dezember 2024, 13:50:51 MEZ:
> > > > On Friday, 6 December 2024 12:08:46 CET, Christophe Marin wrote:
> > > > > Slightly related to this release, packagers need to know what to do
> 
> with
> 
> > > > > packages depending on Qt 5 and marble:
> > > > > 
> > > > > - kgeotag (1.6.0 release only supports KF5/Qt5)
> > > > > - kphotoalbum (5.13 release  only supports KF5/Qt5, but the
> > > > > marble dependency
> > > > > is optional)
> > > > > - kexi (no release for the past 5 years)
> > > > 
> > > > Just to add some piece of information here, because one could get the
> > > > impression that Marble is a hard dependency of kexi. Actually it's
> > > > optional
> > > > as well. And while the current release searches for (Kexi)Marble, the
> > > > respective subdir is commented out (and still is in git master), so
> > > > I'd
> > > > say
> > > > it doesn't depend on marble at all the moment.
> > > > 
> > > > > - kreport (no release for the past 5 years)
> > > > 
> > > > It's an optional dependency there, too.
> > > > 
> > > > > I'm not expecting users will notice if we drop kexi and kreport, but
> > > 
> > > having
> > > 
> > > > > solutions for the other ones before the 24.12 release would be nice.
> > > > 
> > > > Seems we're not particular good at foreseeing such things...
> > > > Six days isn't much time, but I added Tobias in CC to hear if a
> > > > soonish
> > > > release of a Qt6-based kgeotag may be realistic.
> > > > 
> > > > Regards,
> > > > Heiko
> > > 
> > > PS: Maybe also important: The next KGeoTag release will be buildable
> > > both
> > > against Qt6/KF6 as well as Qt5/KF5, whereas the next KPA release will be
> > > Qt6/ KF6-only.
> > 
> > Unless you really really have a reason to support both Qt5 and Qt6 (i.e.
> 
> it's
> 
> > a plugin or library) I would really suggest you support just one (Qt6
> > preferably).
> 
> Hi Albert,
> 
> for KGeoTag, it was no big deal to keep it compatible with both Qt 5 and Qt
> 6 (not so for KPA), so I thought it wouldn't hurt for now? At least as long
> as I can still use Qt 5 on my Gentoo box or using some LTS distro VM (like
> the oldest still-maintained Ubuntu or such, the plan was to support Qt 5
> until Ubuntu LTS is Qt-6-based if possible).
> 
> Of course it would be no problem to drop Qt 5 compatibility with the next
> release, this would strip down to removing the respective parts of
> CMakeLists.txt along with that one QT_VERSION_CHECK macro call in main.cpp I
> needed.
> 
> But just to understand the reasoning: Why is it bad to still support Qt 5 if
> it's possible without noteworthy effort?

Because at the end it is a noteworthy effort.

For each distribution packager that sees that the code compiles with both Qt, 
they have to decide/investigate "which is the good/really supported one".

For each bug you get, if it's in Qt5 and you're usually running Qt6 (or the 
other way around) you have to double guess if it's a bug in the code, a bug in 
Qt, the user being unclear, etc. If you can remove a variable, it's a good 
thing.

For each patch that people send, they need to make sure it compiles against 2 
Qt versions that may not be trivial for them to check.

It makes it a bit harder for our translations since our model really only 
supports one development_branch+Qt combination and you are having two (master-
KF5 and master-KF6) 

It also makes it harder for our sysadmins since like the distribution 
packagers they don't know which is branch is "the good one", so they don't 
know if removing the Qt5 build would be a fatal blow for the project or not.

For each gitlab pipeline that runs, we're potentially causing more climate 
change for not even a good reason (if the previous points have somewhat 
convinced you).

It deviates from our general practives, we usually only support one Qt 
(partial exception being plugins and libraries) except when we are in process 
of porting the app, so when i go to KGeoTag and see it builds with Qt5 and 
Qt6, my immediate thinking is that Qt5 is the good one and that Qt6 support is 
still being worked on.

I really understand and support the desire for the code to build in something 
old as Ubuntu LTS (We normally have that in Okular too) but in this case it 
means until 2026 which may not really be feasible.

Cheers,
  Albert

> 
> Cheers, Tobias
> 
> > Cheers,
> > 
> >   Albert