add qt6 support to debian packaging #60831
Conversation
jef-n
force-pushed
the
deb-qt6
branch
4 times, most recently
from
896731a to
f149340
Compare
|
Why include qwt in external? |
commit 584f203da7cc902aa52a5f3aeda8fa97cae8fdb2 |
Why not ? Why not proposing a package ? Is there an explicit reason described somewhere ? I think we should refrain from adding more and more libraries to external. |
I don't know. There is a qwt-6.2 package supporting qt5 and qt6 in debian experimental for ages (see https://tracker.debian.org/pkg/qwt). Quoting the package page: "package will soon be part of the auto-qwt transition", but I don't know since when that note is there - I suspect long. |
🪟 Windows buildsDownload Windows builds of this PR for testing. 🪟 Windows Qt6 buildsDownload Windows Qt6 builds of this PR for testing. |
use of more up to date system nlohmann headers and not to use the external meshoptimizer headers although the system's library ought to be used)
(debian doesn't have qwt for Qt6 and likely won't have it for trixie)
…ion of multiple versions (eg. qt5 and qt6)
@sebastic Any idea on this? |
There was a problem hiding this comment.
I'm -1 on merging it as this. The external folder is growing constantly with new dependencies, It's not sustainable. Are we planning to add any dependency that have some packaging issues on any of the distribution we are supporting ?
The solution should be to fix the qwt package and make it happen in debian.
The maintainer of the qwt package was last active in December 2023, someone needs to salvage the qwt package to bring it back to active maintenance. I don't want to be that person, as I already maintain too many packages I don't actually use myself.
Yes, that would be the preferred solution, but who is going to do the work? Perhaps QGIS can fund someone to do this if no one volunteers? Vendoring the dependency is an acceptable solution in my opinion until the package is available in all supported distributions. |
No description provided.