Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#49978 - [powerdevil] Please remove networkmanager dependency

Attached to Project: Arch Linux
Opened by Chuck (foxcm2000) - Thursday, 07 July 2016, 02:02 GMT
Last edited by Antonio Rojas (arojas) - Friday, 07 October 2016, 16:31 GMT
Task Type Feature Request
Category Packages: Testing
Status Closed
Assigned To Antonio Rojas (arojas)
Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No



If humanly possible, please make the dependency on networkmanager-qt and the sub-dependency on networkmanager optional so I don't have to install a crapload of unnecessary software on a desktop machine that has no use for any of these packages.

Additional info:
* package version(s): powerdevil 5.7.0-1 (testing repository)

This task depends upon

Closed by  Antonio Rojas (arojas)
Friday, 07 October 2016, 16:31 GMT
Reason for closing:  Won't fix
Additional comments about closing:  They are build time optional, not runtime optional
Comment by Doug Newgard (Scimmia) - Thursday, 07 July 2016, 04:08 GMT
Not sure how you propose to do that. It don't build without it and it links to the library, making it a hard dep.

You complain that you have no use for NetworkManager on a desktop system, what use do you have for powerdevil?

Edit: nevermind, I see it's a dep of plasma-desktop.
Comment by Antonio Rojas (arojas) - Thursday, 07 July 2016, 06:03 GMT
NM-qt is a hard dependency for powerdevil, made powerdevil optional for plasma-desktop instead.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 08 July 2016, 15:28 GMT
  • Field changed: Percent Complete (100% → 0%)
I have a better solution to propose regarding this issue: make networkmanager an optdep for networkmanager-qt (or powerdevil and nothing for networkmanager-qt, probably makes more sense). This last one does indeed not depends on networkmanager, just checked that right now.

powerdevil works well without NetworkManager installed, but propose additional wlan/wwan/bt powermanagement handling if NetworkManager is installed (or in use, not sure about what is needed exactly).

Personally, I’m not using NetworkManager and don’t want to, and wlan/… PM is handled by TLP here.
Comment by Antonio Rojas (arojas) - Friday, 08 July 2016, 16:25 GMT
I don't like this solution, it feels like an ugly hack. NM-qt is a wrapper for the NM dbus API, so it certainly depends on NM even if it doesn't link to the library, and is useless without it.

Does this actually cause any issue besides taking a few MB of disk space? It shouldn't have any effect if you don't enable the service.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 08 July 2016, 16:44 GMT
Well, I found myself without networking ability after update+reboot (netctl wasn’t working without any explicit error message), because NetworkManager was auto-started by something (the corresponding systemd unit not being enabled) and had to figure that out to finally mask NM service as a solution (don’t know what started it) and reboot to get netctl working again. Since I don’t know what caused this and that it can happens in probably lot of unexpected situations, I would recommend avoiding force-pushing NM.

So, while I also expected no effect without enabling the service, it happened that the service was started anyway, masking it being the only solution at this point (or figuring out what started it, but I don’t know how to do that and whether this is “fixable”).

I agree that NM-qt does nothing on it owns without NM, but AFAIK it’s only used as a dependency by other things (like powerdevil) that use it to access NM API, and never as standalone. So, I don’t really think this is a real issue to move the dependency to the programs that actually use NM (through NM-qt).
Comment by NotFood (notfood) - Saturday, 09 July 2016, 13:17 GMT
Found myself in trouble after update as well.

Please see how Fedora solved the issue:

My vote goes for making networkmanager optdep for networkmanager-qt
Comment by Antonio Rojas (arojas) - Saturday, 09 July 2016, 13:20 GMT
I just tested disabling NM. After restarting Plasma I have no network at all, even though plasma-nm is enabled on the system tray. So it's definitely not Plasma which is starting NM automatically.

Can you check the journal to see what is starting NM on your system? It definitely shouldn't be happening.
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 09 July 2016, 13:25 GMT
Just remembered this for instance:
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 09 July 2016, 13:29 GMT
Also, as far as I’m concerned, I can live with that situation: I’ve just -Rddn’ed NetworkManager like I did for kwallet (because I don’t want to use this one and Chromium ask me to create a new Wallet each time a password field is present on a page), or even with other things like ttf-oxygen that I don’t want on my system. So, one more error line after each pacman transaction is something I can live with.
Comment by Antonio Rojas (arojas) - Saturday, 09 July 2016, 13:35 GMT
@notfood Fedora enables NM by default on install, so we can't compare to them. Besides, pacman doesn't have anything equivalent to Fedora's "recommends" (dependencies that can be removed)
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 09 July 2016, 13:47 GMT
On my system, journal log doesn’t says what started it (just says that it started short after systemd first messages in log, before sddm), but since I have tlp, it should be that. However, you don’t know how many things like that may exist.
Comment by Alex Xu (Hello71) - Saturday, 09 July 2016, 15:31 GMT
systemctl list-dependencies --reverse
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 09 July 2016, 15:39 GMT
So, tlp indeed.
Comment by argo (argo_) - Saturday, 09 July 2016, 21:13 GMT
Actually both NetworkManagerQt and BluezQt were made optional by this commit but it was reverted later due to 5.7's dependency freeze
Comment by Antonio Rojas (arojas) - Tuesday, 12 July 2016, 06:49 GMT
Closing this as I can't think of a reasonable way to fix this without tampering with dependencies. If something is starting NM on your system against your will, you should mask the service.
If someone needs powerdevil and absolutely don't want NM installed on their system, they can either:
- Use a dummy empty package that provides NM (like the akonadi one in AUR)
- Use a powerdevil-light package that includes the aforementioned commit and disables NM-qt and bluez-qt support.

IMO the ideal solution would be for upstream to turn NM and bluez support into a plugin so we can make the dependencies optional (like they are for plasma-workspace). Feel free to suggest this upstream.

If someone can think of a better solution, ask for reopen.
Comment by Oracle Speaks (test0987654321) - Friday, 07 October 2016, 15:29 GMT
  • Field changed: Percent Complete (100% → 0%)
As of Plasma 5.8.0 this has been fixed. The change-log for Powerdevil says:

"Make NetworkManagerQt and BluezQt optional."

Please consider making both networkmanager-qt and bluez-qt optional dependencies.

Thank you for your help.
Comment by Doug Newgard (Scimmia) - Friday, 07 October 2016, 15:31 GMT
They can't be optional deps. They're build time optional, so they're either deps or they're not. This is at the maintainer's discretion.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 07 October 2016, 15:35 GMT
Yes, but at least we can now provide powerdevil-light in AUR easily. Expect it soon. ;)
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 07 October 2016, 15:52 GMT
Here you go:

Please note you need to remove networkmanager-qt and/or bluez-qt (any is enough) first and compile this one after, else it will detect them at build time and compile with them as deps. Or alternatively, build in a clean chroot.
Comment by Antonio Rojas (arojas) - Friday, 07 October 2016, 16:31 GMT
@ArchangeGebriel you can pass -DKF5BluezQt_FOUND=OFF to cmake to pretend that bluez-qt isn't available even if it is.