Phase out dev-qt/qtchooser #225
Conversation
|
hmm why? This should finally start to be useful with the Qt 5->6 transition... |
We were wondering about that. Because upstream apparently considers it 'somewhat obsolete'. It is only providing links to standard system paths for the chosen Qt version, do any packages depend on that? At least for building Qt6 packages we won't need it, as we use eqmake{4,5,6} for that, and had fixed other build systems using qmake-utils.eclass in the past when they had been relying on qt binaries in PATH. |
Any references?
Not exactly. qtchooser is a multiplexing tool. e.g. you can run
Gentoo packages should NOT depend on qtchooser behavior, they should discover the appropriate Qt installation prefix through whatever means (this is implicit if using eqmake) and use the binaries from that prefix. Of course I'm sure there are buggy packages that don't do this correctly and will break when the default ( qtchooser and |
|
This started with a user (amadio) asking about 'qtconfig' not working, which lead to me noticing that it was removed from 'qttools' back in 2014, and that 'qtchooser' was last updated back in 2018. At that time I didn't really have a grasp of what and how 'qtchooser' is to be used, but got some pointers from qt-labs IRC channel, so I guess it indeed can still be useful to users. Today I finally got to asking the author of 'qtchooser' about this, and they explained that the old tools can not be removed due to older versions still having them, and they may be in use. As for Qt 6, they do not plan to update 'qtchooser' for it, and instead, "need to adopt non-conflicting names or paths". So with all this in mind, should our Qt packages still pull 'qtchooser' in or not? |
I was actually aware of that and then conveniently shortened its abilities, you're right.
The validity of this RDEPEND is the main focus here then: Line 116 in 5c76498 |
|
This just in [1].
|
|
Yeah I saw that whole thread. Upstream seems to finally understand that version-suffixed binaries are a better approach, although I'm not sure if the maintainers actually reached consensus on doing the renaming upstream (it's quite late in the development cycle) or they're letting each distro take care of it (which would suck). Either way, qtchooser is definitely dead. Now the question is what to do with existing Qt5 installations, which we still need to support for the foreseeable future. A few options:
|
|
Pushed a solution following 4.: Symlink all binaries or check with upstream's recommendations [1] [1] Upstream could go for that as well: https://lists.qt-project.org/pipermail/development/2020-November/040626.html |
|
Can't push Qt 5.15.2 right now anyway because once again, QtWebEngine does not build - neither 5.15.2 nor 5.15.9999, with different errors.... |
Going forward here, assembling the list of binaries to symlink-with-suffix according to the upstream discussion linked above:
Considering it is going to be no longer part of Qt6, maybe install it un-suffixed:
Finally, binaries we could(?) install w/o suffix in
Out of them only Also mentioned in the discussion, but ultimately declared (Qt-)developer-only so not necessary to be in PATH:
This way we will end up with way less symlinks than qtchooser provided. It may cause build issues with a few packages that have inferior build systems but I would expect most of them have already been fixed during Qt4 -> Qt5 transition. @Pesa @kensington @Chiitoo what are your thoughts on this?
|
|
Something going wrong-like with jumbo-build? |
|
I see. Have not bumped into that myself. As for all the rest, I'll trust the judgement of you and the others. I can't think of anything wrong or anything to add. |
a17r
force-pushed
the
nomorechooser
branch
2 times, most recently
from
7b52211
to
722d867
Compare
|
So, implemented all of #225 (comment) with symlinks now because that was the cheapest way to do it. |
|
Some numbers: Rebuilt 102 non-KDE revdeps of dev-qt/qtcore on my system.
Probably not too bad but for sure there will be some additional bugs like that. |
|
@Pesa do you want more links? should link creation be rather done in the respective ebuilds? |
|
Also:
|
That was one of my least favorite, as it will (likely) break things for users and other packages, and I'm not sure if it's worth it now that Qt5 is essentially in maintenance mode... But I won't stop you if you want to deal with the fallout ;) Moreover, while I also prefer just "5" as suffix, it won't help much at this point because: 1) it's a breaking change within gentoo as I said above, 2) it's not consistent with what other major distros have been using ("-qt5"), 3) it's also different from vanilla binaries from upstream which are not versioned. The only advantage is that it would be consistent with Qt6, but that's a pretty weak motivation IMHO. That being said, it's ultimately up to you since you're doing all the work :)
I'd prefer that, yes. |
Agree with the above.
Or unSLOT those packages. Users should just use the latest and greatest and not care if it's Qt5- or Qt6- or Qt7-based. And there should not be any reasons to keep multiple versions simultaneously installed. I'm fine either way though.
It seems to me the ML discussion has been somewhat inconsistent wrt the criterion used to decide whether a binary should be in PATH or not. Sometimes they use "developer tool vs user-facing tool", other times "typically/often run manually by a human vs typically run by a build system or by some other program". IMHO the latter criterion is the correct one, but ultimately let's be consistent with other distros and potentially add a few more symlinks if they make our life easier.
Applying the same logic used for assistant, I'd suggest to leave it alone (i.e., unversioned symlink in PATH), since there won't be a Qt6 version AFAIK. |
a17r
force-pushed
the
nomorechooser
branch
2 times, most recently
from
10fbbfa
to
e617d59
Compare
a)
c) Any suffix in PATH will break assumptions - but that can be alleviated by still providing qtchooser for manual install and keeps b) alive; will need news item and wiki update. But I'm not dead set on that and maybe @kensington has something to say about it as well. Yup, I like consistency, but we can still easily change the suffix until the last minute and we are in no hurry after I pushed 5.15.2 already to tree anyway. Can't hurt in case upstream still change their mind or flesh out more details.
All 3
Indeed, they should have had defined those terms beforehand. We can also forward this topic to |
eclass/qt5-build.eclass
Outdated
| case ${PN} in | ||
| assistant|linguist|qdbus|qdbusviewer) | ||
| SLOT=0 ;; | ||
| linguist-tools|qtdiag|qtimageformats|qtpaths|qttranslations) |
There was a problem hiding this comment.
qtgraphicaleffects and qtquickcontrols should be here too (pure QML modules)
and what about qtplugininfo?
There was a problem hiding this comment.
qtplugininfo is treated as user-facing in Qt6, but I don't know if the Qt6 tool can read Qt5 metadata (and vice versa).
There was a problem hiding this comment.
qtgraphicaleffects and qtquickcontrols should be here too (pure QML modules)
Both are installing so files although in some private subdirectory... no headers though, so I guess this is fine.
There was a problem hiding this comment.
qtplugininfo is treated as user-facing in Qt6, but I don't know if the Qt6 tool can read Qt5 metadata (and vice versa).
Let's keep it at slot 5 then while we are unsure.
There was a problem hiding this comment.
qtgraphicaleffects and qtquickcontrols should be here too (pure QML modules)
Both are installing so files although in some private subdirectory... no headers though, so I guess this is fine.
yes the .so files just provide the (compiled C++) implementation of the QML components. By "pure QML" I meant that the modules have a QML-only API, they don't have a C++ API.
There was a problem hiding this comment.
qtplugininfo is treated as user-facing in Qt6, but I don't know if the Qt6 tool can read Qt5 metadata (and vice versa).
Let's keep it at slot 5 then while we are unsure.
Agreed. Should we symlink it though?
| - uic3 \ | ||
| - xmlpatterns \ | ||
| - xmlpatternsvalidator \ | ||
| + uic3 |
There was a problem hiding this comment.
would it make sense to also drop the obsolete symlinks while at it, such as uic3, qml1plugindump, etc.? I can get a list if you think it's worthwhile
There was a problem hiding this comment.
iirc I made some research for those binaries as for when they got obsolete, and I didn't want to drop them for at least Qt4 users (maybe even Qt3 but I have no idea if qtchooser was even relevant for them, and one could argue someone interested in that should use TQt3 instead these days).
There was a problem hiding this comment.
yeah, makes sense. I was concerned about collisions with Qt6 binaries/symlinks in /usr/bin (such as qmljs) but I guess those will have a "6" suffix, so ignore me.
afaik toralf has been (and still is, I guess) running his tinderbox with qtchooser in package.provided since January 2021, without additional fallout. I see two cases that we would not catch with build errors: a) ebuilds with These two possibilities we need to make maintainers aware of. |
a17r
force-pushed
the
nomorechooser
branch
2 times, most recently
from
3771164
to
98202a1
Compare
a17r
force-pushed
the
nomorechooser
branch
2 times, most recently
from
5377788
to
8dc1d46
Compare
|
gentoo-dev mail draft: https://gist.github.com/a17r/b622b0be3e1e613f1f45c0b35c5196ee |
|
|
||
| src_install() { | ||
| qt5-build_src_install | ||
| qt5_symlink_binary_to_path qml 5 |
There was a problem hiding this comment.
I believe there's a few more here... in Qt6 the following are considered user-facing:
$ git grep qt_internal_add_app
tools/qml/CMakeLists.txt:qt_internal_add_app(qml
tools/qmleasing/CMakeLists.txt:qt_internal_add_app(qmleasing
tools/qmljs/CMakeLists.txt:qt_internal_add_app(qmljs
tools/qmlpreview/CMakeLists.txt:qt_internal_add_app(qmlpreview
tools/qmlscene/CMakeLists.txt:qt_internal_add_app(qmlscene
(qmlscene is deprecated in favor of qml in Qt6, but that's none of our business)
I don't know if the same tools should also be considered user-facing (and thus symlinked with suffix) in Qt5, but it seems a good starting point?
(and no, the classification criteria still don't make any sense to me... why is qmljs user-facing? sure, it can be manually invoked by a developer using Qt, but the same applies to qmllint, qmlprofiler, and several others...)
There was a problem hiding this comment.
I need to work on the draft as well to not confuse what we mean with user-facing... Anyway, yes let's symlink those others too then. We should just drop the term and simply align with whatever upstream does with Qt6.
There was a problem hiding this comment.
well, upstream uses USER_FACING in their cmake files... but yes, I agree on aligning with whatever upstream does.
a17r
force-pushed
the
nomorechooser
branch
3 times, most recently
from
d72633d
to
da51a89
Compare
|
Changes: Added '5' suffix to dev-qt/qtxmlpatterns as it should have been. Dropped that part of the compatibility patch from qtchooser. |
a17r
force-pushed
the
nomorechooser
branch
2 times, most recently
from
1db3541
to
89e85e5
Compare
|
Pending Qt 5.15.3 version bump based on this: gentoo/gentoo#24628 |
Why? I thought the unsuffixed name made for sense for xmlpatterns binaries, it's very similar to the |
Because it is also installing headers, so we can't give it slot '0', which would make it somewhat an outlier if installed suffixless. But it wouldn't conflict with older Qt either, as I at first thought. |
I don't think that's a problem. |
|
Okay then. I will
We may have had the same conversation in the past about this and I just forgot. |
|
...saying that, I check qtxmlpatterns dev branch and notice 2 changes: |
Yeah I'm not sure why they even bothered... the first change looks automated/scripted, the second one is a no-op. |
At the same time we can discuss if/how to replace it.
EDIT 2021-01-10: Remaining list of revdeps: https://qa-reports.gentoo.org/output/genrdeps/rindex/dev-qt/qtchooser