Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 512252 - <sys-power/upower-0.99 pulls in sys-apps/systemd (read: upgrade to >=sys-power/upower-0.99 or move to sys-power/upower-pm-utils)
Summary: <sys-power/upower-0.99 pulls in sys-apps/systemd (read: upgrade to >=sys-powe...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal QA (vote)
Assignee: Gentoo Quality Assurance Team
URL:
Whiteboard:
Keywords:
: 512276 512318 515228 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-06-03 06:34 UTC by Norman Back
Modified: 2014-07-02 23:09 UTC (History)
8 users (show)

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


Attachments
upower-0.9.23-r4.ebuild (upower-0.9.23-r4.ebuild,2.12 KB, text/plain)
2014-06-11 11:41 UTC, Chí-Thanh Christopher Nguyễn
Details
upower-0.99.0-r2.ebuild (upower-0.99.0-r2.ebuild,2.15 KB, text/plain)
2014-06-11 11:41 UTC, Chí-Thanh Christopher Nguyễn
Details
upower-10000.ebuild (upower-10000.ebuild,696 bytes, text/plain)
2014-06-11 11:41 UTC, Chí-Thanh Christopher Nguyễn
Details
upower-pm-utils-0.9.23-r2.ebuild (upower-pm-utils-0.9.23-r2.ebuild,2.42 KB, text/plain)
2014-06-11 11:42 UTC, Chí-Thanh Christopher Nguyễn
Details
emerge -uDpv --tree world (upower-tree.txt,6.44 KB, text/plain)
2014-07-01 14:45 UTC, Nolan Eakins
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norman Back 2014-06-03 06:34:45 UTC
sys-power/upower-0.9.23-r3 requires systemd but I am still using openrc

Reproducible: Always

Steps to Reproduce:
1. emerge -1av =sys-power/upower-0.9.23-r3
2.
3.
Actual Results:  
upower pulls in sys-apps/systemd

Expected Results:  
upower does not pull sys-apps/systemd

emerge --info
Portage 2.2.8-r1 (default/linux/amd64/13.0/desktop, gcc-4.7.3, glibc-2.17, 3.14.5-gentoo-64 x86_64)
=================================================================
System uname: Linux-3.14.5-gentoo-64-x86_64-AMD_Phenom-tm-_II_X4_965_Processor-with-gentoo-2.2
KiB Mem:    16446172 total,    103360 free
KiB Swap:   34602996 total,  34602996 free
Timestamp of tree: Tue, 03 Jun 2014 01:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.2
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 3.1.9 [disabled]
app-shells/bash:          4.2_p45
dev-java/java-config:     2.2.0
dev-lang/python:          2.7.6, 3.3.3
dev-util/ccache:          3.1.9-r3
dev-util/cmake:           2.8.12.2
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.9.6-r3, 1.11.6, 1.12.6, 1.13.4
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.6.3, 4.7.3-r1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.13 (virtual/os-headers)
sys-libs/glibc:           2.17
Repositories: gentoo local ikelos systemd
Installed sets: @kde-4.12, @kernels
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=amdfam10 -mtune=amdfam10 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=amdfam10 -mtune=amdfam10 -O2 -pipe"
DISTDIR="/mnt/portage.autofs/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps=y -j9 --load-average=8 --quiet-build=y"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://mirror.qubenet.net/mirror/gentoo/ http://mirrors.linuxant.fr/distfiles.gentoo.org/ ftp://mirror.qubenet.net/mirror/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ http://mirror.leaseweb.com/gentoo/ http://gentoo.modulix.net/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://mirror.bytemark.co.uk/gentoo/"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j9 --load-average=8"
PKGDIR="/mnt/portage.autofs/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/ikelos /var/lib/layman/systemd"
SYNC="rsync://datastoreone/gentoo-portage"
USE="3dnow X a52 aac accessibility acl acpi alsa amarok amd64 amr authdaemond bash-completion berkdb bluetooth bluray branding bzip2 cairo caps cdda cdr cli consolekit cracklib crypt cups cxx dbus dri dts dv dvd dvdr dvdread emboss encode exif fam firefox flac fortran gdbm gif gpm gtk iconv ieee1394 ipv6 jpeg kde lcms ldap libnotify lm_sensors lock mad mmx mng modules mp3 mp4 mpeg multilib mysql ncurses network nls nptl ofx ogg opengl openmp oss pam pango pcre pdf png policykit ppds qt3 qt3support qt4 readline samba sasl sdl semantic-desktop session spell sse sse2 ssl startup-notification svg tcpd thunar tiff truetype udev udisks uk_bleb uk_rt unicode upower usb v4l v4l2 vdpau vorbis wxwidgets x264 xcb xine xinerama xml xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias cgi cgid" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="lvm syslog" DVB_CARDS="usb-dib0700" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby19 ruby20" SANE_BACKENDS="hp5590 hp net abaton agfafocus apple artec artec_eplus48u as6e avision bh canon canon630u canon_dr canon_pp cardscan coolscan coolscan2 coolscan3 dc210 dc240 dc25 dell1600n_net dmc epjitsu epson epson2 fujitsu genesys gt68xx hp3500 hp3900 hp4200 hp5400 hpljm1005 hpsj5s hs2p ibm kodak kvs1025 kvs20xx leo lexmark ma1509 magicolor matsushita microtek microtek2 mustek mustek_pp mustek_usb nec niash p5 pie pixma plustek plustek_pp pnm qcam ricoh rts8891 s9036 sceptre sharp sm3600 sm3840 snapscan sp15c st400 stv680 tamarack teco1 teco2 teco3 test u12 umax umax1220u umax_pp xerox_mfp" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Anton Bolshakov 2014-06-03 06:50:07 UTC
I've been told to run the following workaround:
emerge -1 sys-power/upower-pm-utils

and it worked.

Now, to the bigger point: I would never guess what I have to switch to a new package. This is NOT user-friendly and NOT how it supposed to be.

I suggest to get the "systemd" USE flag back (via virtual/upower?..) and pull a necessary package based on USE flags settings
Comment 3 Samuli Suominen gentoo-dev 2014-06-03 06:53:00 UTC
(In reply to Anton Bolshakov from comment #1)
> I suggest to get the "systemd" USE flag back (via virtual/upower?..) and
> pull a necessary package based on USE flags settings

virtuals won't do any good here when the dependency syntax can be about 10 different, package by package basis
the gentoo-x86 (official portage tree) has proper deps in every ebuild
Comment 4 Anton Bolshakov 2014-06-03 06:58:04 UTC
(In reply to Samuli Suominen from comment #3)
> (In reply to Anton Bolshakov from comment #1)
> > I suggest to get the "systemd" USE flag back (via virtual/upower?..) and
> > pull a necessary package based on USE flags settings
> 
> virtuals won't do any good here when the dependency syntax can be about 10
> different, package by package basis
> the gentoo-x86 (official portage tree) has proper deps in every ebuild

I suggested virtual as an example I'm sure you can find a better way.

But I believe that the end user should not read all forums and look for workarouds. Ideally, he/she should be able just to run "emerge -DNu world" every time.

Please try to think how to make the upgrade smoother and re-open the bug if it's possible

ps. I'm also expecting few dups of this bug report ;-)
Comment 5 Anton Bolshakov 2014-06-03 08:01:26 UTC
I can also suggest to push a message to "eselect news" if that's the only way.
Comment 6 Samuli Suominen gentoo-dev 2014-06-03 11:52:59 UTC
*** Bug 512276 has been marked as a duplicate of this bug. ***
Comment 7 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-03 14:50:31 UTC
I think the path chosen here is not optimal, because it unnecessarily prevents world upgrades.
Comment 8 Samuli Suominen gentoo-dev 2014-06-03 14:55:05 UTC
(In reply to Chí-Thanh Christopher Nguyễn from comment #7)
> I think the path chosen here is not optimal, because it unnecessarily
> prevents world upgrades.

User needs to do manual decision what he wants to use, no way for Portage to decide it for him.
He can either migrate to 0.99.0, or stay with ~upower-0.9.23 and go with systemd as upower upstream deprecated everything but systemd in 0.9.23 series, or move on to the "forked" / 0.9 git branch / upower-pm-utils special package.
Any auto moving to the special package would have been very wrong, to move from official upower to something that will likely morph into an hack.
And updates/ doesn't support version strings with 'move', so there's no ebuild or profile changes that will help here.
Well, creating systemd base profiles would help, but that's another story.
Comment 9 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-03 15:04:22 UTC
(In reply to Samuli Suominen from comment #8)
> Any auto moving to the special package would have been very wrong, to move
> from official upower to something that will likely morph into an hack.

A news item which alerts users to this fact with Display-If-Installed: sys-power/upower-pm-utils and telling them to migrate to systemd or face potential breakage would be sufficient.

> And updates/ doesn't support version strings with 'move', so there's no
> ebuild or profile changes that will help here.
> Well, creating systemd base profiles would help, but that's another story.

Transitional packages would help, this has been done many times already.
Comment 10 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-06-03 15:31:33 UTC
[[ Order of the quotes has changed; first part important, rest can be skipped ]]

From developer perspective, no freedesktop / QA hat involved; personal thoughts:

(In reply to Samuli Suominen from comment #8)
> He can either migrate to 0.99.0, or stay with ~upower-0.9.23 and go with
> systemd as upower upstream deprecated everything but systemd in 0.9.23
> series, or move on to the "forked" / 0.9 git branch / upower-pm-utils
> special package.

If only Portage would present this choice in a neat way; instead, it gives confusing output that only fanatics and developers can make sense of. With the lack of that, a news item helps out a lot which is what we should focus on now.

(In reply to Chí-Thanh Christopher Nguyễn from comment #9)
> A news item which alerts users to this fact with Display-If-Installed:
> sys-power/upower-pm-utils and telling them to migrate to systemd or face
> potential breakage would be sufficient.

+1 A news item that covers both upower and upower-pm-utils would be nice.

[[ What follows is rant to think about, not a solution right now; unfortunate ]]

> (In reply to Chí-Thanh Christopher Nguyễn from comment #7)
> > I think the path chosen here is not optimal, because it unnecessarily
> > prevents world upgrades.
> 
> User needs to do manual decision what he wants to use, no way for Portage to
> decide it for him.

No, an user should be able to tell Portage that he doesn't want systemd; which should then further translate into making the right decision here for the user, Funtoo's mix-ins work out well for this. With the lack of that, expanding the profiles to choose from could work out in the meantime...

(Side thoughts: Assuming an OpenRC and a systemd stage3 in the future; the OpenRC stage3 could perhaps even get a nosystemd mix-in by default. If not, it could be made clear during the handbook; and perhaps, even be made as a "featured" mix-in in documentation. Many possibilities here...)

> Any auto moving to the special package would have been very wrong, to move
> from official upower to something that will likely morph into an hack.
> And updates/ doesn't support version strings with 'move', so there's no
> ebuild or profile changes that will help here.

If you mask A of || ( A B ) in packages.mask in a profile; then, the users that use that profile will be switched to B by Portage. Given that the visibility of A is gone, due to the mask; as a result, || ( A B ) evaluates to B.

No need for updates/ magic; a mask will do, though we don't have the right place for it due to the lack of proper mix-ins (or alternatively, even more profiles directories). Therefore, a news item seems the only way forward to me for now.

> Well, creating systemd base profiles would help, but that's another story.

Well, my intention is not to keep throwing / discussing mix-ins around here so this'll be the only rant comment, especially not since it isn't a solution that can be applied due to the lack of specification and implementation available.

It is something we've got to keep in mind in the long run depending on what other cases we'll come across in the future, the amount we've been through is certainly reasonable but who knows what more there is to come.
Comment 11 Samuli Suominen gentoo-dev 2014-06-03 15:56:44 UTC
I sent a draft news item to ML, faster you comment on it, faster you get it committed
Comment 12 Marek Behun 2014-06-03 19:24:16 UTC
# equery d upower
 * These packages depend on upower:
net-misc/networkmanager-0.9.8.8 (sys-power/upower)
xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)

Is this forcing me to switch to systemd if I want to use NetworkManager, or XFCE?
Comment 13 Samuli Suominen gentoo-dev 2014-06-03 19:45:46 UTC
closing since the news item was released
Comment 14 Samuli Suominen gentoo-dev 2014-06-03 19:49:27 UTC
(In reply to Marek Behun from comment #12)
> # equery d upower
>  * These packages depend on upower:
> net-misc/networkmanager-0.9.8.8 (sys-power/upower)
> xfce-base/xfce4-session-4.10.1-r1 (udev ? <sys-power/upower-0.99)
> xfce-extra/xfce4-power-manager-1.2.0-r2 (<sys-power/upower-0.99)
> 
> Is this forcing me to switch to systemd if I want to use NetworkManager, or
> XFCE?

Your `equery d` is showing old information. Run `emerge --sync` first, then `emerge -C upower`, then `emerge -1 upower-pm-utils`, then `emerge xfce4-session xfce4-power-manager networkmanager` and you should be good to go.
Read the Portage news item that was announced today, it will come with --sync too.

As in, no, you don't have to install systemd, you have multiple different options, and migrating to upower-pm-utils is one of them.

But this is wrong place for help, please use gentoo-user mailing list or forums.gentoo.org for help
Comment 15 Samuli Suominen gentoo-dev 2014-06-03 20:20:49 UTC
*** Bug 512318 has been marked as a duplicate of this bug. ***
Comment 17 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-11 11:41:04 UTC
Created attachment 378692 [details]
upower-0.9.23-r4.ebuild

For reference, here is my proposed solution using a transitional upower-10000 package. One difference between my mailing list proposal and this one is that there is no longer a new package for upower without pm-utils support, but instead a new slot.

* stable upower users which don't have systemd installed would migrate to upower-pm-utils without any block message
* systemd or ~arch users would go to upower-0.99.0
Comment 18 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-11 11:41:25 UTC
Created attachment 378694 [details]
upower-0.99.0-r2.ebuild
Comment 19 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-11 11:41:50 UTC
Created attachment 378696 [details]
upower-10000.ebuild
Comment 20 Chí-Thanh Christopher Nguyễn gentoo-dev 2014-06-11 11:42:18 UTC
Created attachment 378698 [details]
upower-pm-utils-0.9.23-r2.ebuild
Comment 21 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-06-11 13:18:46 UTC
(In reply to Chí-Thanh Christopher Nguyễn from comment #17)
> For reference, here is my proposed solution using a transitional
> upower-10000 package. One difference between my mailing list proposal and
> this one is that there is no longer a new package for upower without
> pm-utils support, but instead a new slot.

This transitional ebuild has complex deps, makes choices instead of the user as well as doesn't take rev deps into account. Instead of the ebuild hacks that were considered, we have both a news message and mask in place that covers most of it.

> * stable upower users which don't have systemd installed would migrate to
> upower-pm-utils without any block message

Instead of having a simple choice for the user to reconsider; this in a complex way forces them to use a fork, for which no continued support is guaranteed.

> * systemd or ~arch users would go to upower-0.99.0

This doesn't take into account that most reverse dependencies don't support that; beyond that, there is no reason to force this switch for anyone given that for example MATE together with systemd and =sys-power/upower-0.9.23-r3 works well.
Comment 22 Samuli Suominen gentoo-dev 2014-06-27 04:04:34 UTC
*** Bug 515228 has been marked as a duplicate of this bug. ***
Comment 23 Nolan Eakins 2014-07-01 14:37:21 UTC
Cross posting this comment. I attached some emerge output to my duplicate...

I'd have posted to the forums but my account got froze for 30 minutes because I couldn't remember my password, but this is a bug in Portage.

Updating my status, by masking upower-0.99 and using upower-0.9.23-r3 alongside upower-pm-utils with everything else up to date, systemd no longer suspends when I press my power button even when HandlePowerKey=suspend. XFCE has also lost the battery status icon. Bravo!

As far as resolving the upower-0.99 and upower-pm-utils block, is the latter supposed to work with the former? I thought upower-pm-utils was just a compatibility layer for upower-0.99.

I do wish there was a utility to make posting all this emerge logs easier as copying from a tmux session on a remote machine is a PITA. I'm attaching `emerge -uDpv --tree world` and `emerge --info`. I doubt this will tell anyone anything as this is a fairly stock install.
Comment 24 Nolan Eakins 2014-07-01 14:45:45 UTC
Created attachment 380048 [details]
emerge -uDpv --tree world

This is my blocker: upower-pm-utils-0.9.23 blocking upower-0.99.
Comment 25 Nolan Eakins 2014-07-01 15:01:45 UTC
I had to unmask the following to get emerge to stop complaining about a block:
<pre>
<net-im/telepathy-mission-control-5.17.0 **
<gnome-extra/gnome-power-manager-3.13.0 **
<app-misc/tracker-1.2.0 **
<sys-libs/libosinfo-0.3.0 **
<media-libs/libmediaart-0.5.0 **
</pre>

I'd still like to know why portage insisted on upgrading upower and pulling in upower-pm-utils even though it could not perform the upgrade?
Comment 26 Rick Farina (Zero_Chaos) gentoo-dev 2014-07-01 15:25:46 UTC
(In reply to Nolan Eakins from comment #24)
> Created attachment 380048 [details]
> emerge -uDpv --tree world
> 
> This is my blocker: upower-pm-utils-0.9.23 blocking upower-0.99.

You should NEVER have both installed. That blocker is 100% correct. As the news item said, systemd users should be using upower, and non-systemd users should be using upower-pm-utils (most likely, but anything Samuli says is likely better informed to listen to him).
Comment 27 Nolan Eakins 2014-07-01 15:59:22 UTC
So the guidance from https://bugs.gentoo.org/show_bug.cgi?id=515228#c1 is worthless? I just need upower then? Why was upower-pm-utils ever pulled in then? Do the packages I unmasked have borked dependencies?
Comment 28 Samuli Suominen gentoo-dev 2014-07-01 16:20:59 UTC
*** Bug 515228 has been marked as a duplicate of this bug. ***
Comment 29 Samuli Suominen gentoo-dev 2014-07-01 16:25:00 UTC
(In reply to Nolan Eakins from comment #24)
> Created attachment 380048 [details]
> emerge -uDpv --tree world
> 
> This is my blocker: upower-pm-utils-0.9.23 blocking upower-0.99.

And it's obvious why it's happening from your output:

[nomerge       ]      net-im/telepathy-mission-control-5.14.1  USE="upower -connman -debug -gnome-keyring -networkmanager" 
[ebuild  N     ]       sys-power/upower-pm-utils-0.9.23-r2  USE="introspection -ios" 0 kB

Version 5.14.1 of telepathy-mission-control is not happy about new upower, and Portage doesn't know what to do, so it tries to pull in upower-pm-utils, which isn't what systemd users want, so they would upgrade to at least 5.16.1, or disable USE="upower" for telepathy-mission-control

--tree is pretty handy, try learn to read the dependency tree it gives you :)

also, futher help is available at http://forums.gentoo.org/
Comment 30 Pacho Ramos gentoo-dev 2014-07-01 16:39:45 UTC
(In reply to Samuli Suominen from comment #29)
> (In reply to Nolan Eakins from comment #24)
> > Created attachment 380048 [details]
> > emerge -uDpv --tree world
> > 
> > This is my blocker: upower-pm-utils-0.9.23 blocking upower-0.99.
> 
> And it's obvious why it's happening from your output:
> 
> [nomerge       ]      net-im/telepathy-mission-control-5.14.1  USE="upower
> -connman -debug -gnome-keyring -networkmanager" 
> [ebuild  N     ]       sys-power/upower-pm-utils-0.9.23-r2 
> USE="introspection -ios" 0 kB
> 
> Version 5.14.1 of telepathy-mission-control is not happy about new upower,
> and Portage doesn't know what to do, so it tries to pull in upower-pm-utils,
> which isn't what systemd users want, so they would upgrade to at least
> 5.16.1, or disable USE="upower" for telepathy-mission-control
> 
> --tree is pretty handy, try learn to read the dependency tree it gives you :)
> 
> also, futher help is available at http://forums.gentoo.org/

Shouldn't sys-power/upower-0.9.23-r3 be enough and, then, no block at all? (and, also, people running systemd not going to upower-pm-utils because the fixed telepathy-mission-control is pending for Gnome 3.12?)
Comment 31 Samuli Suominen gentoo-dev 2014-07-01 17:02:16 UTC
(In reply to Pacho Ramos from comment #30)
> Shouldn't sys-power/upower-0.9.23-r3 be enough and, then, no block at all?
> (and, also, people running systemd not going to upower-pm-utils because the
> fixed telepathy-mission-control is pending for Gnome 3.12?)

portage sees 0.99.0-r1 stable, tries to upgrade, old telepathy-mission-control preventing it, and instead of staying with old upower, Portage decides to go with option 2, and migrate over to upower-pm-utils

we have eg. bug 515230 and multiple more for improving the dependency resolver, nothing from this bug will advance that cause

also, still missing the systemd profiles, so we'd have a place to mask sys-power/upower-pm-utils for systemd users as "redudant" and help Portage dependency resolver like that

yes, portage has packages that only work with old upower, only work with upower-pm-utils, only work with new upower, only with without systemd, only with with systemd, ... and it will be a reality users will be facing more and more, upower being just one of the first of these

and as in can see, the portage output in this case was more than sufficient to help user do the right decision, so keeping this bug open or filing useless duplicates will help nothing, unless it comes with a profiles/ patch that adds systemd profiles, or sys-apps/portage patch that improves dependency resolver

so, http://forums.gentoo.org/ is more suitable venue for helpdesk
Comment 32 Nolan Eakins 2014-07-01 17:39:26 UTC
I think Portage resolves dependencies fine for the most part. It doesn't work if you come up with a bad $DEPENDS which is what the packages that pulled in upower-pm-utils have.

Maybe something like the following in telempathy-mission-control's case:

        upower? ( || (
                systemd? ( >=sys-power/upower-0.9.11 <sys-power/upower-0.99 )
                !systemd? ( sys-power/upower-pm-utils )
                ) )

I imagine the situation is the same in the other ebuilds that I had pull in upower-pm-utils.

IMO, these changes should have stayed masked much longer. At least until the rest of the tree caught up. I'm okay with not having the latest latest. I'd rather have hands-free updates.
Comment 33 Samuli Suominen gentoo-dev 2014-07-01 18:18:28 UTC
It's not that simple as you said. this has been discussed to death too many times now.

Waiting in this particular case for telepathy-mission-control stabilization as done together with GNOME 3.12+ stabilization will increase conflicts for openrc users, but reduce them for systemd users. And openrc is still the Gentoo default, and stable is sane as it can be for openrc users.
Apologies if you, as a systemd user, will now have to make the manual decision between upgrading telepathy-mission-control, uninstalling it, using upower-pm-utils on a systemd (yes, that's possible too), or disabling it's USE="upower" for it (temporarily or not).

Bottom line is, there is no single right answer, and you really have to deal with upower package-by-package basis.
Comment 34 Nolan Eakins 2014-07-02 12:10:53 UTC
I was suggesting that upower-0.99 remain masked longer. telepathy-mission-control and a few other ebuilds that insisted on upower-pm-utils need their dependencies tweaked so that upower-0.9.23 is preferred over upower-pm-utils if using systemd, and never upower-0.99. I guess that matches the guidance I've read here. Perhaps virtual/upower is required.
Comment 35 Nolan Eakins 2014-07-02 12:41:19 UTC
I had to unmask these to keep upower-pm-utils out.

<net-im/telepathy-mission-control-5.17.0 **
<gnome-extra/gnome-power-manager-3.13.0 **
<app-misc/tracker-1.2.0 **
<sys-libs/libosinfo-0.3.0 **
<media-libs/libmediaart-0.5.0 **
<app-cdr/brasero-3.12.0 **

I'm going unstable. :\
Comment 36 Samuli Suominen gentoo-dev 2014-07-02 14:02:03 UTC
(In reply to Nolan Eakins from comment #34)
> I was suggesting that upower-0.99 remain masked longer.
> telepathy-mission-control and a few other ebuilds that insisted on
> upower-pm-utils need their dependencies tweaked so that upower-0.9.23 is
> preferred over upower-pm-utils if using systemd, and never upower-0.99. I
> guess that matches the guidance I've read here. Perhaps virtual/upower is
> required.

I don't know enough about telepathy-mission-control to know if that would be the right change or not. Does telepathy-mission-control version <5.16 like 5.14.1 expect hibernate and suspend functionality from upower, or does it support it through systemd? Or does it expect the hibernate and suspend functionality at all?

Of course, if you are right, and the change is safe and doesn't break the functionality of old telepathy-mission-control, that'd be an ebuild bug and new bug should be filed against the specific ebuild version
(But I wouldn't want to do such change myself as non-maintainer, non-user, and someone who hasn't reviewed the sources of telepathy-mission-control)
Comment 37 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-07-02 14:14:50 UTC
(In reply to Samuli Suominen from comment #36)
> I don't know enough about telepathy-mission-control to know if that would be
> the right change or not. Does telepathy-mission-control version <5.16 like
> 5.14.1 expect hibernate and suspend functionality from upower, or does it
> support it through systemd? Or does it expect the hibernate and suspend
> functionality at all?
> 
> Of course, if you are right, and the change is safe and doesn't break the
> functionality of old telepathy-mission-control, that'd be an ebuild bug and
> new bug should be filed against the specific ebuild version
> (But I wouldn't want to do such change myself as non-maintainer, non-user,
> and someone who hasn't reviewed the sources of telepathy-mission-control)

The only thing telepathy-mission-control needs from upower is listening to notify-sleep and notify-resume signals, so this means upower-pm-utils or <upower-0.99.

In telepathy-mission-control-5.16, support for systemd was added as an alternative to upower-pm-utils.
Comment 38 Samuli Suominen gentoo-dev 2014-07-02 14:20:51 UTC
(In reply to Alexandre Rostovtsev from comment #37)
> (In reply to Samuli Suominen from comment #36)
> > I don't know enough about telepathy-mission-control to know if that would be
> > the right change or not. Does telepathy-mission-control version <5.16 like
> > 5.14.1 expect hibernate and suspend functionality from upower, or does it
> > support it through systemd? Or does it expect the hibernate and suspend
> > functionality at all?
> > 
> > Of course, if you are right, and the change is safe and doesn't break the
> > functionality of old telepathy-mission-control, that'd be an ebuild bug and
> > new bug should be filed against the specific ebuild version
> > (But I wouldn't want to do such change myself as non-maintainer, non-user,
> > and someone who hasn't reviewed the sources of telepathy-mission-control)
> 
> The only thing telepathy-mission-control needs from upower is listening to
> notify-sleep and notify-resume signals, so this means upower-pm-utils or
> <upower-0.99.
> 
> In telepathy-mission-control-5.16, support for systemd was added as an
> alternative to upower-pm-utils.

right, so the deps are right and "patch" in Comment #32 is a no-go. just as I expected.
Comment 39 Nolan Eakins 2014-07-02 23:09:48 UTC
Read telepathy-mission-control's 5.14.1, latest that's unmasked, $RDEPEND:

    upower? ( || (
                ( >=sys-power/upower-0.9.11 <sys-power/upower-0.99 )
                sys-power/upower-pm-utils
                ) )

Read that carefully: use upower < 0.99 OR upower-pm-tools. If upower 0.99 gets pulled in, then the 2nd line matches creating a blocker. There's nothing to prevent upower from updating to 0.99 here. Hence this is a buggy dependency.

I assume simaliar deps exist in those other ebuilds, but I won't push much more as the packages I unmasked are on track to be unmasked soon.