I think `qttools` should make its `qdbus` USE flag conditioned on the global `dbus` USE flag. Or, does it make sense to turn on whatever optional features `qdbus` controls, when `dbus` is disabled globally?
Most qttools USE are named after the tools they provide (literally called "qdbus" and such), and kept that way to make it easy to identify what you're missing if a tool you need is not found (likewise for ebuilds depending on specific tools)... and not based on what they depend on. Likewise USE=assistant is not named USE=sqlite (also a global USE) because it needs qtbase[sqlite]. Another tool could end up needing dbus in the future too, and then wouldn't necessarily want to put them both behind USE=dbus (could have extra dependencies). On a related note, originally idea was to do like Qt5 and split qttools in several packages, but that turned out to be difficult because of how upstream setup Qt6's qttools and at this point we're probably going to stick with USE-style and flip defaults if a tool is trivial-enough (qdbus is tiny) and is needed by major packages. Given the "majority" of users do not disable dbus (esp. desktop users that would use Qt6), I'd rather these few users just disable qdbus manually than make some exception. Sorry.
Created attachment 887256 [details, diff] Make `qdbus` conditional on `dbus` I think you misunderstand. I didn't ask you to CHANGE the `qdbus` USE flag only to make its effect *conditioned* on the global `dbus` USE flag. You appear to have at least a basic understanding of how conditional USE flags work; so, I don't really grasp why you'd want to inconvenience the "minority" of Gentoo users who don't use/need/want `dbus`, when you could change a few lines in the ebuild; no "exceptions" required. All I'm asking is that you replace this line: > qdbus? ( ~dev-qt/qtbase-${PV}:6[dbus,xml] ) by the following > dbus? ( qdbus? ( ~dev-qt/qtbase-${PV}:6[dbus,xml] ) ) AND, adjust IUSE accordingly, i.e add `dbus` and change from `+qdbus` to `qdbus`. I'm not sure why that's so contentious... especially considering that this makes logical sense, since `qdbus` won't be useful on a `dbus`-free system. BTW, if you could share the source of the statistics that supports your claim that > the "majority" of users do not disable dbus I'd be grateful. It's not that I don't believe you, I'm just interested in the actual numbers. If you have that broken down by desktop vs non-desktop users, and users/non-users of Qt6 that would be even better!
That's terrible, and that's why I wouldn't think it's what you meant. That makes USE=qdbus essentially lie about providing the tool. Revdeps would even need to depend on qttools[qdbus,dbus] to be sure they get it. In that situation I would do like with USE=clang, and have REQUIRED_USE="qdbus? ( dbus )" and if you set USE=-dbus globally that would still require you to unset qdbus anyway making that useless. If you have a dbus-free system, then just unset qdbus.
(In reply to Ionen Wolkens from comment #3) > That's terrible, and that's why I wouldn't think it's what you meant. That > makes USE=qdbus essentially lie about providing the tool. Revdeps would even > need to depend on qttools[qdbus,dbus] to be sure they get it. Oh wait, you didn't disable it in the patch. But it requires qtbase[dbus] to build.. so it'd just fail to build? qt_internal_add_app(qdbus SOURCES qdbus.cpp LIBRARIES Qt::DBusPrivate Qt::Xml )
Also note that having it enabled by default is a goal unless major desktop packages stop needing it (it was going to be enabled by profiles alternatively). So it's not going from +qdbus to qdbus.
(In reply to Another Mortal from comment #2) > I'd be grateful. It's not that I don't believe you, > I'm just interested in the actual numbers. If you have > that broken down by desktop vs non-desktop users, and > users/non-users of Qt6 that would be even better! Many packages with a dbus IUSE enable it by default, it's further a global default on desktop profiles, and dbus is essentially unavoidable if you have anything using GTK unless using intrusive patches. Majority do not go out of their way to go against this to avoid a tiny package. I see no reason to believe otherwise even though we do not collect statistics (on anything). Makes sense to be missing on a server, but I'm speaking in a Qt context which typically means it is for desktop USE bare rare exceptions.
> That makes USE=qdbus essentially lie about providing the tool. Not true in all the "usual" setups where `dbus` is enabled by default. BUT, you're entirely correct that BOTH `dbus` AND `qdbus` would need to be enabled for the tool to get built. And, that's exactly the idea... ;-) And, yes, that implies this statement could very well be correct: > Revdeps would even need to depend on qttools[qdbus,dbus] to be sure they get it. > In that situation I would do like with USE=clang, and have > REQUIRED_USE="qdbus? ( dbus )" and if you set USE=-dbus globally > that would still require you to unset qdbus anyway making that useless. Exactly! Which is why I could label that approach terrible, but I actually think it's more truthful, and gives the right diagnostic on a DBus-free system. That would save time trying to locate what's sneaking in `dbus`. > If you have a dbus-free system, then just unset qdbus. Sure. I could do that. I was hoping I didn't have to, but I will, if we cannot find an agreeable solution. > Oh wait, you didn't disable it in the patch. > But it requires qtbase[dbus] to build.. so it'd just fail to build? > > qt_internal_add_app(qdbus > SOURCES > qdbus.cpp > LIBRARIES > Qt::DBusPrivate > Qt::Xml > ) I'm not sure I follow. I only tested building with `dbus` disabled, and `qdbus` not enabled by default, which seems to work fine. I'd expect the same with both enabled, but I haven't actually checked. > So it's not going from +qdbus to qdbus. Noted. In that case, disabling it conditionally won't work, I'm afraid. Not without other changes in the ebuild, in any case. > Majority do not go out of their way to go against this to avoid a tiny package. I think that's a valid assumption, but still an assumption without data. Also, avoiding DBus has nothing to do with size. It's about hygiene. > Makes sense to be missing on a server, but I'm speaking in a Qt context > which typically means it is for desktop USE bare rare exceptions. I use Wayland with Sway, with very few packages linking to GTK/Qt. And, I've yet to see a major practical drawback of not having DBus, beyond Firefox not being able to launch a new window from the CLI (a weird design, irrespective of DBus or not, but that's another story).
