Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 586302 - 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
Summary: app-misc/tracker, gnome-extra/cinnamon-settings-daemon, mate-extra/mate-power...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL: https://qa-reports.gentoo.org/output/...
Whiteboard: Was: app-misc/tracker, gnome-extra/ci...
Keywords:
Depends on: 596988
Blocks:
  Show dependency tree
 
Reported: 2016-06-18 16:52 UTC by Michał Górny
Modified: 2019-03-31 19:44 UTC (History)
8 users (show)

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


Attachments
mate-session-manager patch ck2 (0001-Replace-deprecated-upower-functions-with-ConsoleKit2.patch,16.31 KB, patch)
2017-01-28 00:36 UTC, Sander Sweers
Details | Diff
mate-power-manager patch ck2 (0001-Replace-deprecated-UPower-functions-with-ConsoleKit2.patch,7.68 KB, patch)
2017-01-28 00:37 UTC, Sander Sweers
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-18 16:52:36 UTC
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.
Comment 1 NP-Hardass gentoo-dev 2016-06-18 21:36:00 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?
Comment 2 Alexandre Rostovtsev (RETIRED) gentoo-dev 2016-06-19 18:58:04 UTC
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.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-19 20:10:04 UTC
(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.
Comment 4 Pacho Ramos gentoo-dev 2016-06-20 14:33:22 UTC
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)
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-21 19:10:35 UTC
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.
Comment 6 Pacho Ramos gentoo-dev 2016-06-24 11:15:00 UTC
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?
Comment 7 NP-Hardass gentoo-dev 2016-06-27 22:35:03 UTC
(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?
Comment 8 Jason Zaman gentoo-dev 2016-06-28 04:06:43 UTC
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.
Comment 9 NP-Hardass gentoo-dev 2016-06-28 15:29:47 UTC
(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?
Comment 10 Pacho Ramos gentoo-dev 2016-06-28 15:34:54 UTC
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 :/
Comment 11 Pacho Ramos gentoo-dev 2016-06-28 15:37:33 UTC
(CCing consolekit maintainers to ensure they follow all the thread ;)
Comment 12 Jason Zaman gentoo-dev 2016-06-30 08:14:36 UTC
(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.
Comment 13 Michael Palimaka (kensington) gentoo-dev 2016-06-30 19:47:13 UTC
(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.
Comment 14 Joakim Tjernlund 2016-07-25 19:20:07 UTC
(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.
Comment 15 NP-Hardass gentoo-dev 2016-07-25 19:28:59 UTC
(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?
Comment 16 Joakim Tjernlund 2016-07-25 22:28:25 UTC
(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
Comment 17 Joakim Tjernlund 2016-11-30 01:26:10 UTC
(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?
Comment 18 Joakim Tjernlund 2016-11-30 01:43:45 UTC
(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?
Comment 19 Pacho Ramos gentoo-dev 2016-12-04 12:08:19 UTC
You should open a new bug for that concrete issue with that concrete package... probably blocking tracker bug 596988
Comment 20 Sander Sweers 2017-01-28 00:36:39 UTC
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
Comment 21 Sander Sweers 2017-01-28 00:37:28 UTC
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
Comment 22 Sander Sweers 2017-01-28 00:39:56 UTC
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.
Comment 23 Pacho Ramos gentoo-dev 2017-01-31 21:32:08 UTC
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
Comment 24 Andreas Sturmlechner gentoo-dev 2018-08-25 05:41:38 UTC
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.
Comment 25 Joakim Tjernlund 2018-08-25 13:28:53 UTC
MATE 1.18 has the mentioned patches included upstream, just rm
earlier MATE versions from the tree.
Comment 26 Mart Raudsepp gentoo-dev 2018-08-25 17:29:34 UTC
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.
Comment 27 Mart Raudsepp gentoo-dev 2018-09-16 09:20:51 UTC
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.
Comment 28 Christoph Schulz 2018-11-23 19:30:31 UTC
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).
Comment 29 Andreas Sturmlechner gentoo-dev 2018-11-23 19:41:33 UTC
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.
Comment 30 Andreas Sturmlechner gentoo-dev 2018-12-25 11:43:44 UTC
upower-pm-utils is gone. Pacho, anything left to do here?
Comment 31 Pacho Ramos gentoo-dev 2019-01-03 13:08:32 UTC
I think all is done and people can depend on upower:0= finally
Comment 32 Andreas Sturmlechner gentoo-dev 2019-03-31 19:44:16 UTC
I guess we'll close this then.