KDE Gear 24.12.0 packages available for packagers

[Tobias Leupold]

E-Mail von Albert Astals Cid vom Sonntag, 8. Dezember 2024, 12:12:41 MEZ:
> 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

Woah, okay -- I see. Thanks for the comprehensive explanation. Well, then I 
think a reasonable approach would be to remove the Qt 5 support with the next 
release. I think this will take some time anyway, and thus Marble >=24.12 will 
already have landed in most (non-LTS) distros, so that there's no problem.

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