Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644112 - kde-plasma/powerdevil doesn't respect global networmanager USE flag
Summary: kde-plasma/powerdevil doesn't respect global networmanager USE flag
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
: 845363 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-10 10:34 UTC by Andrew
Modified: 2022-05-18 20:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 2018-01-10 10:34:03 UTC
When wireless flag of kde-plasma/powerdevil is enabled which is the default (+wireless in the ebuild) the package will pull in net-misc/networkmanager as a dependency (transitively through kde-frameworks/networkmanager-qt) even when the global networkmanager flag is disabled. I feel like powerdevil should respect networkmanager USE flag. E.g. wireless use flag can be replaced by two separate networkmanager and bluetooth global USE flags. Another approach might be to make the wireless flag dependent on networkmanager being set. These are just some ideas from top of the head, there may be a much better solution.

I use netifrc for network configuration which is incompatible with Network Manager so I don't want to have it installed. The problem is solved on my machine by disabling wireless USE flag for kde-plasma/powerdevil and masking net-misc/networkmanager to not get it pulled in accidentally but it would be nice to address it globally.

Version of kde-plasma/powerdevil I use is 5.10.5
Comment 1 Michael Palimaka (kensington) gentoo-dev 2018-01-10 10:42:31 UTC
The ebuild is simply mirroring upstream's options:
> set(HAVE_WIRELESS_SUPPORT FALSE)
> if(KF5NetworkManagerQt_FOUND AND KF5BluezQt_FOUND)
>     set(HAVE_WIRELESS_SUPPORT TRUE)
> endif()
> add_feature_info(
>     "Wireless power saving"
>     HAVE_WIRELESS_SUPPORT
>     "Support turning off signal-transmitting devices to save energy"
> )
Comment 2 Andreas Sturmlechner gentoo-dev 2018-01-10 11:16:24 UTC
We won't introduce a second USE flag without purpose. And USE=networkmanager instead of wireless would not describe the functionality well in context of powerdevil. In this case there is one option being enabled, that incidentally covers WiFi and Bluetooth, not just one or both. To reach your goal one could introduce lots of additional 'virtual' use flags that serve no purpose other than to describe the *dependency* in addition to the *function* combined with sophisticated REQUIRED_USE dependencies. And it would be a massive pain to administer, not just for devs but also users, with USE flag conflicts guaranteed on every little change.
Comment 3 Andrew 2018-01-10 13:11:34 UTC
I'm quite new to Portage, please excuse my ignorance.

Why REQUIRED_USE="wireless? ( networkmanager )" won't cut it?

Another option I see it to use combination of wifi, bluetooth and networkmanager flags combined as a replacement of wireless. E.g. in DEPEND (not sure if something like that works):

wifi? (bluetooth? (networkmanager?(
	$(add_frameworks_dep bluez-qt)
	$(add_frameworks_dep networkmanager-qt)
)))

Thanks for taking time to consider the suggestions.
Comment 4 Andreas Sturmlechner gentoo-dev 2018-01-10 23:41:32 UTC
(In reply to Andrew from comment #3)
> Why REQUIRED_USE="wireless? ( networkmanager )" won't cut it?
- Two USE flags to describe one option.
- We use REQUIRED_USE only if absolutely necessary when two or multiple *actual* build options are interacting with each other, not to explain simple package dependencies, because each instance means another possible showstopper for users on emerge.
- This solution would work if we generally agreed to do such constructs (adding virtual USE flags solely to enforce them globally), but it scales very badly for the aforementioned reason.

(In reply to Andrew from comment #3)
> wifi? (bluetooth? (networkmanager?(
> 	$(add_frameworks_dep bluez-qt)
> 	$(add_frameworks_dep networkmanager-qt)
> )))
- Three USE flags to describe one option.
- That is having 2^3 USE flag combinations out of which 7 end up building with the same outcome of having wireless powersaving disabled, without being obvious to the user. The REQUIRED_USE construct to make this work explicitly would be really awful.

What it comes down to is: One can never serve everyone. When in doubt, the simple solution wins. USE flags are seldomly able to switch off a dependency globally - often users are wondering why they still need Qt4 given that they switched off USE=qt4 globally, only to find out one or several of their packages simply hard-depend on it. Regardless, Portage should be able to tell you the source of the networkmanager dependency, and it appears it did, given that you found out to disable USE=wireless for powerdevil.
Comment 5 Michael Palimaka (kensington) gentoo-dev 2018-01-12 09:56:21 UTC
As Andreas mentioned, we strive to avoid USE flags that do nothing on their own.

USE flags represent support for something. It's a nice coincidence that this sometimes matches up with some other package name (like ffmpeg) but this is not always the case. With powerdevil, upstream exposes a wireless feature that unconditionally requires both dependencies so that's what we expose. 

In an ideal world maybe we'd have some sort of mechanism to "link" USE flags so that we could have individual bluetooth and networkmanager USE flags and have one automagically enable the other.

Unfortunately, we currently don't have any such mechanism. As a result, having multiple flags that can be toggled and do nothing (eg. USE="bluetooth -networkmanager") could at be confusing (where's my bluetooth support!?) or very annoying (unsatisfied REQUIRED_USE constraints are a pain to resolve). Also, it's against Gentoo QA policy to have USE flags that don't do anything (in addition to being confusing or annoying, it can cause useless rebuilds when toggling USE flags).

For these reasons, we won't be making the suggested ebuild change. However, your feedback is always appreciated and I hope our justification is clear. Please feel free to drop by #gentoo-kde any time if you'd like to chat more about it.
Comment 6 Andrew 2018-01-12 19:39:42 UTC
Andreas, Michael,
Thank you for your detailed explanations, it all makes (more) sense now. I'm starting to grasp slowly what exactly Portage USE flags are.
Comment 7 Andreas Sturmlechner gentoo-dev 2022-05-18 13:21:43 UTC
*** Bug 845363 has been marked as a duplicate of this bug. ***