@ChrisR
I think you have missed the point here
I feel that Chris is being quite polite and positive with his suggestions. When we discuss things, we need to be able to point out problems as we see them, we won't get anything done if we have things that we are not allowed to say. (We do need to recognise that some cultures can be more frank and forthright that others but as long as the intention is not to offend, I try and understand that.)
.....The QT5 widgets is mature, but requires the user to install libqt5pas. However, the Debian versions of this library are out of date, and this causes users confusion:
Chris, The commit to Qt5 widset that triggered that problem has been reversed but that event sure flags an issue that will almost certainly pop up again. I believe we have a problem with version numbering with libqt5pas1, if we had a clear release and number model, it would be easy to convience Distro Packagers to confirm to it. Distro Packagers love version number ! At present, the 'working' version of libqt5pas1 might be only the one in Lazarus trunk. But there is no way Distro Packagers will take code from a trunk. Sensible !
I established that github clone of libqt5pas1 to try and separate it from Lazarus trunk and stamp a sequential version number but that did not, apparently, work. This is probably a separate issue, maybe needs to be in a separate thread.
First of all, I still don't use QT on Linux.
I use GTK, Enlightenment and Moksha:
valdir, from memory (I don't have a viable Enlightenment VM at the moment) E can use the Qt widget set too. One of the people that help me with tomboy-ng is big fan of E, always trying to convert me. I find it too complicated ....
When I was asked to package tomboy-ng for Debian, they told me that new GTK2 apps were not welcome, the only option was Qt5 (that later changed in a complicated story). Right now, there seems to be quite a lot of progress in GTK3 but sadly, still a long way the go. So, really, any new app trying to get into the Debian repo needs to be Qt5. So, we have our work cut out for use !
Since GTK3, GTK4, and QT5 integration to LCL suffers from lack of developers and you are also saying that is an important matter, my suggestion is that you learn that subject to be helpful and get things done.
yep, that applies to us all ! Incidentally, Chris was very helpful in facilitating some of the work involved in adapting to the "Apple Silicon".
The big issue in Debian packaging is they have a policy of breaking things down to small modules to enable reuse. And that makes very good sense most of the time. However, with FPC/Lazarus there is little or no 'cross use', very few other tools can use LCL for example and the IDE is really Pascal (probably FPC) only. But a mob like Debian absolutely has to have rules and must, as much as possible stick to them. Its the only way a project like that can work.
Our standard install of FPC for example puts executable binaries under /usr/lib/fpc..., we then symlink it to /usr/bin. In the debian install, when you call fpc, you get /usr/bin/fpc which is a symlink to /etc/alternatives/fpc that is a symlink to /usr/bin/x86_64-linux-gnu-fpc
That works fine for a fpc user who just wants to build native apps, we could, with some effort, write instructions to use the Debian model to make a cross compiler. Should we ?
The debian model does not work for 'our' Lazarus built, for example from source. Again, the problem is just that Lazarus does not recognise where things are, it could be made to work, again, should we do that ?
Things to do -I am very happy to spend some time documenting the differences between how Debain package FPC/Lazarus compared to 'our' SourceForge model. That may help us decide if there is sufficient common ground to work towards a compromise. I do, however feel it may be too hard ...
I recently re-wrote the instructions to cross compile from Linux ot Windows, at the top I now say, very clearly, "Do not use a Repo version of FPC to do this" - that may well be our only long term solution.
Davo