Just has the case of request for qtdeclarative with no USE=network requirement along with an already installed qtbase[network]. Current ebuild requires to set USE=network for not breaking qtbase[network]. IIUC RDEPEND=" ~dev-qt/qtbase-${PV}:6[...,network?, Would fix such an issue. Reproducible: Always
If you fix upstream's build system first, sure.
Yeah, I forget what it was exactly but in the commit message when I did qml_network: commit fad1f2c38bd881295e92818f8507fb72b37c34b3 Author: Ionen Wolkens <ionen@gentoo.org> Date: Tue Dec 12 16:23:44 2023 dev-qt/qtdeclarative: update live Can avoid the more typical = for ssl ([ssl=]) thanks to having no uncontrolled QT_FEATURE_ssl automagic, but there is some for network.
Albeit for fwiw I think it's somewhat edge cases (no QT_CONFIG usage I think), but I'd rather not have to worry about it (esp. since most people wouldn't disable network in the first place, making the [=] kind of harmless). e.g. if(QT_FEATURE_testlib AND QT_FEATURE_network AND QT_FEATURE_quick_itemview AND TARGET Qt::Test AND TARGET Qt::QuickControls2 AND NOT (WASM AND BUILD_SHARED_LIBS)) add_subdirectory(quickcontrolstestutils) endif() And QT_FEATURE_network is not something should be turning off on non-qtbase packages, this is very messy when attempt it. In case unclear, the thing is that if you build: 1. qtbase[network] 2. qtdeclarative[-network] ^ this qtdeclarative would still attempt to use network for some bits even with the flag disabled 3. qtbase[-network] ^ allowed because qtdeclarative doesn't depend on it .. and then qtdeclarative now has some broken bits, [network=] prevents this
