| Summary: | x11-misc/xdg-utils-1.2.1-r2: wrong name for qtpaths binary on gentoo | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kris Scott <kris> |
| Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | IN_PROGRESS --- | ||
| Severity: | minor | CC: | chiitoo, ionen, kde, kris, qt |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 935416 | ||
|
Description
Kris Scott
2024-06-25 23:32:54 UTC
I just noticed I put the wrong package in the title. The package in question is x11-misc/xdg-utils-1.2.1-r2, not xdg-mime which does not exist. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b779d4b7e4ae652539320473991663dffa366abf commit b779d4b7e4ae652539320473991663dffa366abf Author: Sam James <sam@gentoo.org> AuthorDate: 2024-07-03 22:34:19 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-07-03 22:35:29 +0000 x11-misc/xdg-utils: fix qtpaths for KDE Plasma Pending questions: * Should qt6paths instead be in /usr/bin in Gentoo? * Why do we have a qtpaths6 as well as a qt6paths? But add this emergency fix for now given it may manifest in confusing and hard-to-diagnose ways. Bug: https://bugs.gentoo.org/934941 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/hppa/package.use.mask | 4 + profiles/arch/ia64/package.use.mask | 4 + profiles/arch/powerpc/ppc32/package.use.mask | 4 + profiles/arch/s390/package.use.mask | 4 + profiles/arch/sparc/package.use.mask | 4 + .../xdg-utils/files/xdg-utils-1.2.1-qtpaths.patch | 21 ++++ x11-misc/xdg-utils/xdg-utils-1.2.1-r3.ebuild | 106 +++++++++++++++++++++ 7 files changed, 147 insertions(+) Note that for Qt6 we haven't been arbitrarily deciding what should be in /usr/bin or not so far and simply following what Qt6 upstream tells us to do in [1]. There is currently 0 manual symlinks and the few like /usr/bin/qmake6 are from user_facing_tool_links.txt And qt6paths? That sounds like an invention from another distro unless I'm missing something. qtpaths6 is what Qt uses in the private bin dir, albeit they haven't marked it USER_FACING and thus does not appear in user_facing_tool_links.txt (whether it should be or not, is another question). [1] https://doc.qt.io/qt-6/packaging-recommendations.html Ah, sorry, I think I transposed the two: qt6paths vs qtpaths6. If we really needed it, not against doing a manual /usr/bin/qtpaths6 anyhow (but should ideally be changed upstream). Albeit pkg-config doesn't sound too bad if we don't want to invent anything.
<asturm> what I don't get is why we both have /usr/lib64/qt6/bin/qtpaths6 and /usr/lib64/qt6/bin/qtpaths
^ don't really know but it's a hard link and that's just how the build system does it (not from us), they do it for qmake{,6} too -- maybe(?) qtpaths is actually meant to be USER_FACING like qmake6 but it just been an upstream oversight
(In reply to Ionen Wolkens from comment #5) > maybe(?) qtpaths6 is actually meant to be USER_FACING like qmake6 > but it just been an upstream oversight To be more precise, what would need changing in qtbase is: --- a/src/tools/qtpaths/CMakeLists.txt +++ b/src/tools/qtpaths/CMakeLists.txt @@ -12,2 +12,3 @@ TOOLS_TARGET Core + USER_FACING INSTALL_VERSIONED_LINK And then the ebuild would create the /usr/bin/qtpaths6 symlink automatically. (In reply to Ionen Wolkens from comment #5) > maybe(?) > qtpaths is actually meant to be USER_FACING like qmake6 but it just been an > upstream oversight Comment at #qt-labs says "likely yes but would need to look into git history if there is any reason why it wasn't". |
