Summary: | app-misc/tracker, gnome-extra/cinnamon-settings-daemon, mate-extra/mate-power-manager: rethink || ( upower upower-pm-utils ) vs. relying on systemd USE flag for pulling upower+systemd and upower-pm-utils+openrc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | cinnamon+disabled, freedesktop-bugs, joakim.tjernlund, mate, openrc, perfinion, Sander.Sweers, systemd |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://qa-reports.gentoo.org/output/genrdeps/rindex/sys-power/upower-pm-utils | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=571722 | ||
Whiteboard: | Was: app-misc/tracker, gnome-extra/cinnamon-settings-daemon, mate-extra/mate-power-manager: malformed || ( sys-power/upower:= ) dep | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 596988 | ||
Bug Blocks: | |||
Attachments: |
mate-session-manager patch ck2
mate-power-manager patch ck2 |
Description
Michał Górny
2016-06-18 16:52:36 UTC
I think, for MATE, a pm-utils USE flag to toggle between the two is the simplest and most reasonable option. Thanks for bringing it to my attention and proposing multiple solutions and their advantages and disadvantages. Do any of you other maintainers feel that the virtual option would be a better course of action? Looking at the tree, there are lots of ebuilds already using approach 3 (no := operator) for the upower + upower-pm-utils disjunction. For example, see networkmanager, kdelibs, synaptiks, sddm, bunch of xfce4 and lxde packages...
I think that for a reasonable user experience, either all of these should adopt a consistent USE flag, or we can just drop the := operator in c-s-d and tracker until package manager support for := in disjunctions is fixed.
> since the two have different SONAMEs, the virtual would strongly suggest upgrade from upower-pm-utils to upower, unless forced not to (i.e. by masking the newer vesion)
The order of items in the disjunction in dozens of individual ebuilds already has this effect.
(In reply to Alexandre Rostovtsev from comment #2) > Looking at the tree, there are lots of ebuilds already using approach 3 (no > := operator) for the upower + upower-pm-utils disjunction. For example, see > networkmanager, kdelibs, synaptiks, sddm, bunch of xfce4 and lxde packages... I think that's a bug of missing := rather than a rule. However, we could proceed this way until a better solution is found. > I think that for a reasonable user experience, either all of these should > adopt a consistent USE flag, or we can just drop the := operator in c-s-d > and tracker until package manager support for := in disjunctions is fixed. It is doubtful that it will be fixed. It will require the ||= () block that binds to a particular package. It is in queue for a long time, and was proposed for EAPI 6 but nobody volunteered to implement it in Portage. > > since the two have different SONAMEs, the virtual would strongly suggest upgrade from upower-pm-utils to upower, unless forced not to (i.e. by masking the newer vesion) > > The order of items in the disjunction in dozens of individual ebuilds > already has this effect. You did not understand me. I mean virtual/libfoo-1 would pull in pm-utils version, and -3 will pull in upstream upower. So Portage will always try to 'upgrade' to pm-utils unless someone explicitly masks it. Maybe we could rely on the general "systemd" USE flag for the packages still needing the old upower-pm-utils All people running systemd must use plain upower instead of the pm-utils one. The problem is with people running openRC :/ At present time I think that many of the reverse deps will still work with upower-1 even on non-systemd setups, but that wasn't the case in the past when we started to introduce this || ( ) forms. In an ideal world we wouldn't even need upower-pm-utils, that is completely dead for ages (and we are probably the only distributions still allowing people to use it). But I have no idea if all reverse deps are ready to move to plain upower on non-systemd setups. But I am unsure about what to do because each time I have tried to handle this I have found people wanting to run really strange setups (well, last issue I remembered about this was https://bugs.gentoo.org/show_bug.cgi?id=571722 ) In summary, I don't have the information about: - What reverse dependencies are really relying on suspend functionality from upower-pm-utils? That packages (if still existing) should move to "systemd" USE flag to pull in plain upower vs. upower-pm-utils Once we know that, we will be able to decide if we still need to allow other reverse deps to have || ( ) deps to allow easier switch between them :/ Of course I would like to simply kill upower-pm-utils completely instead of keeping this overcomplexity situation and make it worse with virtuals :S.... specially taking care that I think many people pretending to run openrc and pm-utils are really not being able to properly suspend/hibernate their systems (but they are trying to kill any think that could be related with systemd in any way) commit afde709125dbc6a3151ee581dbf87858b2d80e58 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Tue Jun 21 21:08:26 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Tue Jun 21 21:09:19 2016 mate-extra/mate-power-manager: Remove := inside ||, #586302 commit 2e4b3baa78e0e047e48dd3f690d0806f95ed2d91 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Tue Jun 21 21:07:52 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Tue Jun 21 21:09:19 2016 gnome-extra/cinnamon-settings-daemon: Remove := inside ||, #586302 commit 8700bbe5d986d6a407d3db6eb7e58040316422e8 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: Tue Jun 21 21:07:35 2016 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: Tue Jun 21 21:09:19 2016 app-misc/tracker: Remove := slot op inside ||, #586302 I'm leaving the bug open so you can decide how to proceed with reintroducing proper deps throughout the repo. OK, I will CC the involved parties to know their opinions about how to handle this. From my point of view, under "systemd" USE flag we should always force people to run sys-power/upower (allowing us to also use := operator). But I don't know what to do for people running openRC. The should still need to run sys-power/upower-pm-utils for suspending... but I have no idea about how a setup with sys-power/upower and openRC will work regarding the suspending/hibernation :S Also, who in freedesktop project is taking care of pm-utils? (In reply to Pacho Ramos from comment #6) > OK, I will CC the involved parties to know their opinions about how to > handle this. > > From my point of view, under "systemd" USE flag we should always force > people to run sys-power/upower (allowing us to also use := operator). > > But I don't know what to do for people running openRC. The should still need > to run sys-power/upower-pm-utils for suspending... but I have no idea about > how a setup with sys-power/upower and openRC will work regarding the > suspending/hibernation :S > > Also, who in freedesktop project is taking care of pm-utils? Correct me if I'm wrong, but the sys-power/upower package can be, and is used by people on OpenRC, so systemd for the useflag doesn't make sense to me. I think pm-utils as a flag makes the most sense. It's currently used by 5 packages: use.local.desc kde-base/powerdevil:pm-utils - Adds support for suspend/resume the system through sys-power/pm-utils net-misc/wicd:pm-utils - Installs the pm-utils hooks for suspend/resume and requires sys-power/pm-utils sys-apps/razercfg:pm-utils - Installs the pm-utils hooks for suspend/resume and requires sys-power/pm-utils sys-auth/consolekit:pm-utils - Adds support for suspend/resume using sys-power/pm-utils sys-power/powermgmt-base:pm-utils - Adds support for on_ac_power through sys-power/pm-utils I know at least for mate, our description would be the same as the 4, "Adds support for suspend/resume using sys-power/pm-utils" !pm-utils? ( sys-power/upower:= ) pm-utils? ( sys-power/upower-pm-utils ) and for other packages where upower support is entirely optional, just wrap that in a upower? ( ). Might make sense for systemd profiles to set -pm-utils globally since that behavior has been subsumed by systemd, et al. Package maintainers determine whether they want to set +pm-utils, though, IMO, since profiles would be turning off that flag, as just suggested, makes most sense to me to set +pm-utils so non-systemd users get the desired by default. All would be satisfied with minimal effort that way. Thoughts? Just wanted to clarify a few things, upower-pm-utils needs to die, it is a hack and not maintained at all. It was kept around for a while but if possible should be removed. upower dropped suspend support and it moved to systemd-logind and ConsoleKit2 (>=sys-auth/consolekit-1.0). you probably want a dep like: sys-power/upower:= !systemd? ( >=sys-auth/consolekit-1.0 ) xfce4-power-manager has deps like that too. OpenRC has basically nothing to do with this, its really about ConsoleKit2 vs systemd-logind (which are the ones that do login session tracking and suspending). Basically the full set of options are: 1) systemd (+ upower + pm-utils?) 2) >=sys-auth/consolekit-1.0 + sys-power/upower 3) <sys-auth/consolekit-1.0 + sys-power/upower-pm-utils ck-1.0 pulls in pm-utils so 2) is implicitly also sys-power/pm-utils. >=consolekit-1.0 has been stable for ages so you probably do not even want 3) anymore. I will be dropping upower-pm-utils from all the xfce packages too in the next round of bumps. (In reply to NP-Hardass from comment #7) > !pm-utils? ( sys-power/upower:= ) > pm-utils? ( sys-power/upower-pm-utils ) > most sense to me to set +pm-utils so non-systemd users get the desired by > default. Wrong way around, plain upower is the one you want. (In reply to Jason Zaman from comment #8) > Just wanted to clarify a few things, > upower-pm-utils needs to die, it is a hack and not maintained at all. It was > kept around for a while but if possible should be removed. > > upower dropped suspend support and it moved to systemd-logind and > ConsoleKit2 (>=sys-auth/consolekit-1.0). > > you probably want a dep like: > sys-power/upower:= > !systemd? ( >=sys-auth/consolekit-1.0 ) > > xfce4-power-manager has deps like that too. OpenRC has basically nothing to > do with this, its really about ConsoleKit2 vs systemd-logind (which are the > ones that do login session tracking and suspending). > > Basically the full set of options are: > 1) systemd (+ upower + pm-utils?) > 2) >=sys-auth/consolekit-1.0 + sys-power/upower > 3) <sys-auth/consolekit-1.0 + sys-power/upower-pm-utils > > ck-1.0 pulls in pm-utils so 2) is implicitly also sys-power/pm-utils. > >=consolekit-1.0 has been stable for ages so you probably do not even want > 3) anymore. I will be dropping upower-pm-utils from all the xfce packages > too in the next round of bumps. > > (In reply to NP-Hardass from comment #7) > > !pm-utils? ( sys-power/upower:= ) > > pm-utils? ( sys-power/upower-pm-utils ) > > most sense to me to set +pm-utils so non-systemd users get the desired by > > default. > Wrong way around, plain upower is the one you want. Does #2 require that consolekit be built with the pm-utils USE flag? Is #2 a drop-in replacement for #3? or does my software need to be patched? If my software needs to be patched, then I disagree, forcing a default which requires waiting on upstream to update their packages does not sound like "what I want." If it is a drop-in replacement, why aren't we just migrating users away from upower-pm-utils completely? Was the porting to consolekit1 finished? Last time I looked into it, there were still some breakage with reverse deps... but maybe they were solved. If that is the case, probably the way to go would be to kill the old consolekit and upower-pm-utils finally :/ (CCing consolekit maintainers to ensure they follow all the thread ;) (In reply to NP-Hardass from comment #9) > (In reply to Jason Zaman from comment #8) > > Basically the full set of options are: > > 1) systemd (+ upower + pm-utils?) > > 2) >=sys-auth/consolekit-1.0 + sys-power/upower > > 3) <sys-auth/consolekit-1.0 + sys-power/upower-pm-utils > Does #2 require that consolekit be built with the pm-utils USE flag? all that useflag does is pull in pm-utils if the user wants to be able to suspend, its actually a runtime dep but too many users complained so I added it anyway. other packages should not dep on that useflag. > Is #2 a drop-in replacement for #3? or does my software need to be patched? > If my software needs to be patched, then I disagree, forcing a default which > requires waiting on upstream to update their packages does not sound like > "what I want." If it is a drop-in replacement, why aren't we just migrating > users away from upower-pm-utils completely? ck-1.0 completely supersedes ck-0.4.6. It did not remove anything at all so it is always safe to upgrade consolekit. all versions of upower do the actual power things (battery info, on AC etc) suspending is the only problematic point here. <upower-0.99 includes the dbus interfaces for suspending and hibernating. >=ck-1.0 added them. gnome-extra/cinnamon-session and net-im/telepathy-mission-control are the only packages in the tree that dep on upower-pm-utils but not on upower. The session managers might need to be ported probably but I have no idea why an IM client would need to be able to suspend the machine. app-misc/tracker has no references to suspending in upower or consolekit at all so this is not an issue and it can use the new versions of everything. Maybe I should open a tracker bug so we can have a list of packages that still need functionality from upower-pm-utils so we can work towards properly removing it. (In reply to Jason Zaman from comment #12) > Maybe I should open a tracker bug so we can have a list of packages that > still need functionality from upower-pm-utils so we can work towards > properly removing it. This is a great idea. The landscape is a lot different these days with ck2 so it would be great to remove upower-pm-utils is possible. I've also been working with elogind to try and get another option available. (In reply to NP-Hardass from comment #1) > I think, for MATE, a pm-utils USE flag to toggle between the two is the > simplest and most reasonable option. > > Thanks for bringing it to my attention and proposing multiple solutions and > their advantages and disadvantages. > > Do any of you other maintainers feel that the virtual option would be a > better course of action? There are 2 patches on the MATE ml which moves MATE to modern upower/ckit2. Upstream is slow to adopt them though. (In reply to Joakim Tjernlund from comment #14) > (In reply to NP-Hardass from comment #1) > > I think, for MATE, a pm-utils USE flag to toggle between the two is the > > simplest and most reasonable option. > > > > Thanks for bringing it to my attention and proposing multiple solutions and > > their advantages and disadvantages. > > > > Do any of you other maintainers feel that the virtual option would be a > > better course of action? > > There are 2 patches on the MATE ml which moves MATE to modern > upower/ckit2. Upstream is slow to adopt them though. Link? (In reply to NP-Hardass from comment #15) > (In reply to Joakim Tjernlund from comment #14) > > (In reply to NP-Hardass from comment #1) > > > I think, for MATE, a pm-utils USE flag to toggle between the two is the > > > simplest and most reasonable option. > > > > > > Thanks for bringing it to my attention and proposing multiple solutions and > > > their advantages and disadvantages. > > > > > > Do any of you other maintainers feel that the virtual option would be a > > > better course of action? > > > > There are 2 patches on the MATE ml which moves MATE to modern > > upower/ckit2. Upstream is slow to adopt them though. > > Link? That is hard since MATE does not offer a mail archive but I found a gmane archive http://comments.gmane.org/gmane.comp.desktop.mate.devel/309 There are two patches in there: Replace deprecated upower functions with ConsoleKit2 equivalents for mate-power-manager and Replace deprecated UPower functions with ConsoleKit2 equivalents for mate-session-manager (In reply to NP-Hardass from comment #15) > (In reply to Joakim Tjernlund from comment #14) > > (In reply to NP-Hardass from comment #1) > > > I think, for MATE, a pm-utils USE flag to toggle between the two is the > > > simplest and most reasonable option. > > > > > > Thanks for bringing it to my attention and proposing multiple solutions and > > > their advantages and disadvantages. > > > > > > Do any of you other maintainers feel that the virtual option would be a > > > better course of action? > > > > There are 2 patches on the MATE ml which moves MATE to modern > > upower/ckit2. Upstream is slow to adopt them though. > > Link? Should we just apply these two patches in Gentoo? (In reply to Michał Górny from comment #0) > All three listed packages have deps like: > > || ( >=sys-power/upower-0.9:= sys-power/upower-pm-utils ) > > However, := inside || () is forbidden and broken, and must not be used. > > Possible solutions are: > > 1. add a USE flag to toggle between the two implementations (:= inside USE > conditionals is fine); > > 2. introduce a virtual -- however, since the two have different SONAMEs, the > virtual would strongly suggest upgrade from upower-pm-utils to upower, > unless forced not to (i.e. by masking the newer vesion); > > 3. (discouraged) drop the := operator. cinnamon-session-3.2.0.ebuild has: systemd? ( >=sys-apps/systemd-183 ) !systemd? ( >=sys-power/upower-pm-utils-0.9.23 ) No sys-power/upower at all, since the rest of cinnamon supports upower I suspect this is a bug? You should open a new bug for that concrete issue with that concrete package... probably blocking tracker bug 596988 Created attachment 461664 [details, diff]
mate-session-manager patch ck2
This is the patch to replace the old upower code and replace it with ck2. it provides no backward compat
Created attachment 461666 [details, diff]
mate-power-manager patch ck2
This is the patch to replace the old upower code and replace it with ck2. it provides no backward compat
Here are the patches posted to the MATE ml some time ago. They did not care to give feedback other than send it to github which I was not willing to. A bit childish to completely ignore them as they are confirmed working properly by Joakim. I would instead open a separate bug report for each concrete package and make that bugs block this one. That will let the relevant maintainers to take care of the issue more deeply What's the status of this bug? There are still people using upower-pm-utils when they should not, simply out of confusion because it still exists. While packages hard-depending on upower are creating blockers for them. MATE 1.18 has the mentioned patches included upstream, just rm earlier MATE versions from the tree. MATE 1.18 needs to be stabled first. mudler can probably sign-off a stabilization list, but could use help in preparing one. I planned to use our gnome scripts for that, but haven't yet gotten around to it. MATE 1.18 is stable, but there is some reluctance to remove old, as 1.18 doesn't support gtk2... I don't care and want to have as much gtk2 consumers gone as possible. I would like to bring to your attention that the power management features of media-tv/kodi also require upower-pm-utils on non-systemd systems. The dependency !systemd? ( || ( sys-power/upower-pm-utils sys-power/upower ) ) from kodi's ebuilds is therefore wrong, as it suggests that suspend/hibernate functionality is provided on non-systemd systems with either upower or upower-pm-utils (but only the latter works in practice). This bug is neither about kodi nor is any of the assigned and CC'd devs maintaining kodi. To repeat myself: Open a new bug. upower-pm-utils is gone. Pacho, anything left to do here? I think all is done and people can depend on upower:0= finally I guess we'll close this then. |