dev-qt/qtcore:4 did have PDEPEND=~dev-qt/qttranslations-${PV} but in Qt5 this was omitted; currently, the only revdeps are: - dev-qt/qt-creator - lxqt-base/lxqt-meta # see bug 678540 For sure, this will be required in more applications than covered by that. I've checked Arch Linux and their list is: - feathernotes, featherpad - qtqr - baka-mplayer (optional) - pcmanfm-qt (optional) - picard (optional) - qt5-base (testing, optional) - qtcreator (optional) I don't know how thorough that list will be, I imagine it is incomplete. List of installed files by dev-qt/qttranslations-5.15.2 into /usr/share/qt5/translations/ (with varying amount of translations): assistant_en.qm designer_en.qm linguist_en.qm qt_en.qm # qtcore? qt_help_en.qm qtbase_en.qm # qtcore? qtconnectivity_en.qm # qtbluetooth qtdeclarative_en.qm qtlocation_en.qm # qtpositioning qtmultimedia_en.qm qtquickcontrols2_en.qm qtquickcontrols_en.qm qtscript_en.qm qtserialport_en.qm qtwebengine_en.qm qtwebsockets_en.qm qtxmlpatterns_en.qm Imo we have several options: 1) Add dependency to dev-qt/qtcore 1.a) unconditionally 1.b) via IUSE=nls (breaking optional RDEPEND ban) 2) Split up dev-qt/translations into separate packages, PDEPEND from dev-qt/* 3) Merge dev-qt/translations into dev-qt/* packages (mapping see above) 3.a) IUSE=nls, SRC_URI and insinto 3.b) or unconditionally (QA: small files shall not have USE flags) WDYT?
(In reply to Andreas Sturmlechner from comment #0) > dev-qt/qtcore:4 did have PDEPEND=~dev-qt/qttranslations-${PV} but in Qt5 > this was omitted; currently, the only revdeps are: > > - dev-qt/qt-creator > - lxqt-base/lxqt-meta # see bug 678540 > > For sure, this will be required in more applications than covered by that. qttranslations is supposed to be installed by users when needed, for the most part. Some packages (should) depend on it because the package's own translations won't load unless qt translation files are available. > Imo we have several options: > > 1) Add dependency to dev-qt/qtcore > 1.a) unconditionally I assume by "dependency" you mean PDEPEND. This would effectively revert to the qt4 state. Not necessarily bad, but would force dev-qt/linguist-tools and dev-qt/qtxml on everyone. > 1.b) via IUSE=nls (breaking optional RDEPEND ban) What's the "optional RDEPEND ban"? > > 2) Split up dev-qt/translations into separate packages, PDEPEND from dev-qt/* I thought about this in the early days of qt5, it would cause a proliferation of very small packages that's even worse than option 3b IMHO. The only benefit is that it would solve the circular dependency for qtcore. > 3) Merge dev-qt/translations into dev-qt/* packages (mapping see above) This is technically messy to implement for qtcore, given the circular dependencies. > 3.a) IUSE=nls, SRC_URI and insinto > 3.b) or unconditionally (QA: small files shall not have USE flags) Not sure if that QA policy applies, given the extra dev-qt/linguist-tools dependency. Sure, many systems will already have linguist-tools installed because it was pulled by other packages, but that's kind of irrelevant IMHO.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=63e6266e092b22fcdd3dd7db746e8e1d9b3ff39c commit 63e6266e092b22fcdd3dd7db746e8e1d9b3ff39c Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-12-17 16:04:38 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-12-17 16:04:38 +0000 kde-frameworks/kcoreaddons: RDEPEND on dev-qt/qttranslations:5 Use upstream's recommendation to pull in dev-qt/qttranslations:5 in a lower-tier framework. See also: https://mail.kde.org/pipermail/distributions/2021-December/001110.html Bug: https://bugs.gentoo.org/810802 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-frameworks/kcoreaddons/kcoreaddons-9999.ebuild | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f71cb6cf918f242f200504764f3201eab2c52aa commit 6f71cb6cf918f242f200504764f3201eab2c52aa Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-12-17 16:04:38 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-12-17 16:12:24 +0000 kde-frameworks/kcoreaddons: RDEPEND on dev-qt/qttranslations:5 Use upstream's recommendation to pull in dev-qt/qttranslations:5 in a lower-tier framework. See also: https://mail.kde.org/pipermail/distributions/2021-December/001110.html Bug: https://bugs.gentoo.org/810802 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../kcoreaddons/kcoreaddons-5.88.0-r1.ebuild | 54 ++++++++++++++++++++++ .../kcoreaddons/kcoreaddons-5.89.0-r1.ebuild | 54 ++++++++++++++++++++++ 2 files changed, 108 insertions(+)
(In reply to Davide Pesavento from comment #1) > (In reply to Andreas Sturmlechner from comment #0) > > dev-qt/qtcore:4 did have PDEPEND=~dev-qt/qttranslations-${PV} but in Qt5 > > this was omitted; currently, the only revdeps are: > > > > - dev-qt/qt-creator > > - lxqt-base/lxqt-meta # see bug 678540 > > > > For sure, this will be required in more applications than covered by that. > qttranslations is supposed to be installed by users when needed, for the > most part. Some packages (should) depend on it because the package's own > translations won't load unless qt translation files are available. Unfortunately I think we have done a bad job at detecting such packages so far, i.e. there was no awareness revdeps should have to check (nor how) for this necessity. (In reply to Davide Pesavento from comment #1) > (In reply to Andreas Sturmlechner from comment #0) > > 1.b) via IUSE=nls (breaking optional RDEPEND ban) > What's the "optional RDEPEND ban"? No RDEPEND-only IUSE until there is such support in Portage. (In reply to Davide Pesavento from comment #1) > (In reply to Andreas Sturmlechner from comment #0) > > 3) Merge dev-qt/translations into dev-qt/* packages (mapping see above) > This is technically messy to implement for qtcore, given the circular > dependencies. > > > 3.a) IUSE=nls, SRC_URI and insinto > > 3.b) or unconditionally (QA: small files shall not have USE flags) > Not sure if that QA policy applies, given the extra dev-qt/linguist-tools > dependency. Sure, many systems will already have linguist-tools installed > because it was pulled by other packages, but that's kind of irrelevant IMHO. We have another option: Roll our own qttranslations tarball with pre-generated qm files. This opens up 1) and 3) without the dependency problems. Now that Qt5 is effectively "done", I expect minimal maintenance burden.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=53c16fca587360f9975217ca0cea3393d7f85074 commit 53c16fca587360f9975217ca0cea3393d7f85074 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-06 03:39:54 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-06 08:49:36 +0000 dev-qt/qtbase: optionally pdepend on qttranslations For qt6, had bit of a draft to "merge" qttranslations with their respective packages, plus a few splits for circular deps. But it all started to feel churny and looked like it would be a pain to maintain, prone to mistakes, and with very little to gain. Doing our own tarballs could work but still requires some tracking and writing scripts to handle it. And then I do not think translations should need to be emerged manually, it is something you can normally expect out of the box unless you opt-out. So let's just do the "nls? ( )" in qt6 even if runtime-only IUSE are kind of terrible on a large package like qtbase. Not unconditional given it does bring in linguist as extra, and translations are still a decent ~13MB installed. Live-only for now, no need to trigger rebuilds over this. Bug: https://bugs.gentoo.org/810802 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/qtbase-6.5.9999.ebuild | 7 +++++-- dev-qt/qtbase/qtbase-6.9999.ebuild | 7 +++++-- 2 files changed, 10 insertions(+), 4 deletions(-)
