At runtime qtchooser depends on environment variable XDG_CONFIG_DIRS to locate /etc/xdg/qtchooser and falls back to /etc/xdg. src/qtchooser/main.cpp 457: vector<string> xdgPaths = stringSplit(qgetenv("XDG_CONFIG_DIRS", "/etc/xdg").c_str()); The fallback path should be ${EPREFIX}/etc/xdg on Prefix. In gentoo, XDG_CONFIG_DIRS is set by xdg-utils 90xdg-data-base 2:XDG_CONFIG_DIRS="EPREFIX/etc/xdg" So qtchooser should depend on xdg-utils on Prefix or the default /etc/xdg should be prefixified. Reproducible: Always
Created attachment 441292 [details, diff] qtchooser-prefix.patch Depending on xdg-utils is not an option. It draws a lot of packages and environment variables in env.d is only effective on the next login. So this patch will give qtchooser a default path to /etc/xdg on Prefix. Please review. Thanks!
What is hprefixify? And how can it work if there's no marker to replace?
Btw, general high-level prerequisite question, do you/we want to (re-)add prefix support to qt?
(In reply to Davide Pesavento from comment #2) > What is hprefixify? And how can it work if there's no marker to replace? https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/prefix.eclass#n51 Basically, it calls sed -i "s,/etc,${EPREFIX}/etc," while guarding against being too greedy. (In reply to Davide Pesavento from comment #3) > Btw, general high-level prerequisite question, do you/we want to (re-)add > prefix support to qt? I am not sure if it was ever removed. I am interested in supporting prefix QT. I have the whole KDE stack compiled yesterday.
(In reply to Benda Xu from comment #4) > (In reply to Davide Pesavento from comment #3) > > Btw, general high-level prerequisite question, do you/we want to (re-)add > > prefix support to qt? > > I am not sure if it was ever removed. I am interested in supporting prefix > QT. I have the whole KDE stack compiled yesterday. It was very likely broken during the qt4 multilib migration, and prefix keywords were dropped after that (https://bugs.gentoo.org/show_bug.cgi?id=529196#c17). Qt5 has no explicit prefix support, unless it already works out-of-the-box (I'd be surprised). As a general goal, do you want to add prefix support to qt5? I just hope the eclass doesn't become an unmaintainable mess full of huge hacks, like qt4-build.eclass was.
(In reply to Davide Pesavento from comment #5) > (In reply to Benda Xu from comment #4) > > (In reply to Davide Pesavento from comment #3) > > > Btw, general high-level prerequisite question, do you/we want to (re-)add > > > prefix support to qt? > > > > I am not sure if it was ever removed. I am interested in supporting prefix > > QT. I have the whole KDE stack compiled yesterday. > > It was very likely broken during the qt4 multilib migration, and prefix > keywords were dropped after that > (https://bugs.gentoo.org/show_bug.cgi?id=529196#c17). We now have a new branch of prefix (RAP) supporting multilib. https://archives.gentoo.org/gentoo-dev-announce/message/772326d735c8c7c469beffc0a9bb0b97 RAP use implicit keywording (like amd64). No prefix specific keyword (like amd64-linux) for RAP. > Qt5 has no explicit > prefix support, unless it already works out-of-the-box (I'd be surprised). It almost work out-of-the-box, with some trivial fixes. > As a general goal, do you want to add prefix support to qt5? Yes, I do. > I just hope the > eclass doesn't become an unmaintainable mess full of huge hacks, like > qt4-build.eclass was. I don't think much will be needed to support qt5. The Prefix patches are mostly prefixifies as in this bug or some trivial D <-> ED exchanges (like I committed yesterday at https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9e8376cc034e6c5296fed85227542fefcd030f6).
Hi, does it look good to be committed? I am going to land this patch in tree in a week if there is no objections.
I'd prefer if you came up with a proper patch that could be submitted upstream...
(In reply to Davide Pesavento from comment #8) > I'd prefer if you came up with a proper patch that could be submitted > upstream... Hi Davide, it is a `sed`. To submit it upstream, we will need to make /etc a cmake/qmake configurable, and that means a change to the build system. At the moment we don't have that. If you concern is all about the work load of QT/KDE team, the Prefix team would like to commit to maintain these patches. Considering bug 647844, we do have users interested in modern and beautiful QT5 via Prefix on servers running old distributions. What do you think?
Ping Team QT.
*** Bug 673872 has been marked as a duplicate of this bug. ***
Hi Qt Project, I will commit the patch to qtchooser and maintain it for Prefix thereafter if there is no objections in a week. Thank you for your understanding. Yours, Benda
Created attachment 596458 [details, diff] qtchooser.patch Revised patch.
I guess the question meanwhile is: What is qtchooser doing right now for us, or will it become relevant again with Qt6?
Remaining packages using QT_SELECT: games-fps/doomsday app-office/libreoffice sci-visualization/paraview
(In reply to Andreas Sturmlechner from comment #14) > I guess the question meanwhile is: What is qtchooser doing right now for us, > or will it become relevant again with Qt6? Ah-ha, so this is mostly irrelevant to the present Gentoo. We can close this bug.
