port:qt5 and (proposed) port:qt5-kde cohabitation
René J.V. Bertin
rjvbertin at gmail.com
Thu Oct 6 15:12:41 PDT 2016
On Thursday October 06 2016 23:19:38 Marko Käning wrote:
Hi,
> Currently the situation for port qt5-kde is as follows:
> - 5 port groups would have to be updated (see comments 30-34 in [1])
That's a maximum, and this is the main point where we have to come to a consensus.
I'll add that I have gone to great lenghts to ensure that qt5-kde is as much as a drop-in replacement for port:qt5 (and its subports) as possible. There's a protection that prevents installing binary builds made against port:qt5, but in fact this is possible (tested with the binary qt5-creator package for 10.9, a few months back). In other words, users moving from port:qt5 to qt5-kde should not necessarily be obliged to reinstall/rebuild everything also because of the way dependencies are set up in the qt5-kde PortGroup.
> chosen path to offer an alternative port for Qt5, which is dedicated to a
> better user experience for KDE specifically.
In fact, it is required for the upcoming KF5 ports to work as intended, i.e. comparably to the KDE4 ports they will ultimately replace. Too many things don't work as designed when using a "stock" Qt5, and while it's not impossible get them to work you end up with builds that aren't really fit to be MacPorts ports.
> a) find a way to merge qt5 and qt5-kde(-devel) somehow
>
> b) or should we live with offering a dedicated Qt for KDE ??
No offence, but personally I think that we missed the time window in which a merge was feasible (over a year ago). The ports have diverged so much over time since that merging them will be a huge effort which I think neither of us has much interest for.
Two ships, two captains, and we'll have to figure out a way to collaborate on the shared portion of the Qt5 PortGroup .
I really hope we can because the alternative will be bad for users.
> If you’re FOR b), I’d soonish like to commit this port because automated CI
> is simply a must now. Us two doing all the build tests is tedious and error
> prone.
And only one of us has commit rights. It would probably be useful if that changed ...
R.
More information about the macports-dev
mailing list