| Summary: | <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) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Norman Back <gentoo3> |
| Component: | [OLD] Core system | Assignee: | Gentoo Quality Assurance Team <qa> |
| Status: | RESOLVED FIXED | ||
| Severity: | QA | CC: | admwiggin, chithanh, freedesktop-bugs, hrabe, Manfred.Knick, nolan, xms-00, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
upower-0.9.23-r4.ebuild
upower-0.99.0-r2.ebuild upower-10000.ebuild upower-pm-utils-0.9.23-r2.ebuild emerge -uDpv --tree world |
||
|
Description
Norman Back
2014-06-03 06:34:45 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 http://blogs.gentoo.org/news/2014/06/02/gentoo-monthly-newsletter-may-2014/#sys-powerupower_update http://forums.gentoo.org/viewtopic-p-7561774.html#7561774 http://forums.gentoo.org/viewtopic-t-992290-highlight-.html # emerge -C upower # emerge -1 upower-pm-utils (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 (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 ;-) I can also suggest to push a message to "eselect news" if that's the only way. *** Bug 512276 has been marked as a duplicate of this bug. *** I think the path chosen here is not optimal, because it unnecessarily prevents world upgrades. (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. (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. [[ 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. I sent a draft news item to ML, faster you comment on it, faster you get it committed # 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? closing since the news item was released (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 *** Bug 512318 has been marked as a duplicate of this bug. *** 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
Created attachment 378694 [details]
upower-0.99.0-r2.ebuild
Created attachment 378696 [details]
upower-10000.ebuild
Created attachment 378698 [details]
upower-pm-utils-0.9.23-r2.ebuild
(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. *** Bug 515228 has been marked as a duplicate of this bug. *** 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. Created attachment 380048 [details]
emerge -uDpv --tree world
This is my blocker: upower-pm-utils-0.9.23 blocking upower-0.99.
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? (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). 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? *** Bug 515228 has been marked as a duplicate of this bug. *** (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/ (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?) (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 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.
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. 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 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. :\ (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) (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. (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. 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.
|
