Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Wed, 04 Jun 2014 08:44:45 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/04/2014 08:24 AM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Since systemd needs special profiles to be easy to use ... No, these systemd profiles are only introduced for GNOME and KDE ... ... it'd be the boring and easy way to restrict it to those profiles so that dependency changes don't cause this needless amount of work for users, and this indecent amount of mail on this mailinglist ..., which means that your restriction doesn't hold ... Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. I have no idea what you are trying to say, but there's a desktop profile ...; because systemd users also use the desktop profiles ... Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. The default is already that, all I'm suggesting is masking systemd there so that portage doesn't needlessly antagonize users ..., which makes your suggestion not an option. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 03, 2014 at 09:20:51PM -0400, Greg Woodbury wrote: Then, they steal a general kernel command line parameter (debug) that makes booting impossible in certain cases. (Linus had to put his foot down on that one.) Almost your entire statement here is incorrect. Systemd still looks at the debug flag until jorunald is available. There was a bug which caused lots of output from systemd to the kernel, making the kernel hang. Linus subsequently said kernel should rate limit the output from any process, plus was upset the way that Kay handled a bugreport. However, Linus is and was totally fine with the debug flag usage. Aside from that there are various other tools that make use of the debug flag. Apologies if this conflicts with your systemd is taking over the world and evil evil evil talk :-P References (these are more thorough): https://plus.google.com/115547683951727699051/posts/VYRaUuh1tkt https://lwn.net/Articles/593676/ -- Regards, Olav
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Saturday, May 31, 2014 02:17:32 PM Samuli Suominen wrote: On 31/05/14 05:47, Steven J. Long wrote: On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote: On 27/05/14 08:34, Michał Górny wrote: Dnia 2014-05-26, o godz. 23:15:34 Samuli Suominen ssuomi...@gentoo.org napisał(a): UPower upstream removed sys-power/pm-utils support from 0.99 release (currently unkeyworded in tree), as in, from current git master. Don't worry. Looking at the past, I can guess this is only a temporary inconvenience. I'm pretty sure upower will be discontinued soon and replaced with systemd-powerd or something :D. That's more or less what they already did, they forced eg. xfce4-power-manager upstream to move the deleted pm-utils code from upower directly to the power manager (application) itself, likewise for xfce4-session Which means applications will now need to duplicate the pm-utils related code per application basis So I expect upower to be more or less dead for everything but systemd users, except for those upstreams that will actually follow the Xfce path and do the duplication Yet, still, small portition of the code is still 'generic', so xfce4-power-manager will still need both, upower, even 0.99, and then pm-utils, depending on the version, codepath is selected This was sort of expected, since pm-utils has been abandoned for ~5 years now at upstream, so nobody is maintaining non-systemd related power management tools anymore, and falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be necessary again, it's like going back to 90s for non-systemd users :P I can't believe I'm reading that from a distro-developer. Basically this entire thread is systemd is deprecating the existing tools, so let's dump them and half our userbase back to the 90s, isn't that a great thing? Then you misunderstood. Notice the :P as an indicator of sarcasm. I've already created sys-power/upower-pm-utils where the sys-power/pm-utils 0.9 git branch will continue to live. Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. If you need support for understanding Portage's output, try the gentoo-user mailing list. - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 7:25 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. If you need support for understanding Portage's output, try the gentoo-user mailing list. This probably could have used a news item, as the change impacts both stable and ~arch users. They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, otherwise portage is going to try to switch them from udev to systemd, since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. I posted the same on -user... Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. For those failing to read `eix upower` or `emerge -C upower` or masking systemd, or number of other ways the blocker can be solved, the answer is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at Freenode, MLs, pretty much everywhere. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 15:24:22 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. Regardless of that, most acquirements have lead to a news item. For those failing to read `eix upower` That command doesn't tell anything helpful for this blocker. or `emerge -C upower` For that you need to already know that you have to unmerge upower; it is also not going to help anything in terms of dependency calculation, except for a small amount of users that might have selected it. or masking systemd, Masking systemd has the same effect as having udev selected; so, taking this action has zero effect and results in the blocker to still be there. The output has perhaps changed a little, the idea is the same. or number of other ways the blocker can be solved, There is the problem, new Gentoo users can't solve it; that's why it's all over the place, as you've mentioned below. And some of it contains misinformation, like the gentoo-user thread you have responded to. Why do the users need to keep solving these nasty blockers? You could solve it if you use --tree --unordered-display; go through the dependency chain to check the reverse dependencies, write down what is going on and finally come to the conclusion of it all. But how are new users supposed to know all that? Why is --tree --unordered-display still not a default? In other words, why is the list of packages still flat by default? the answer is in Gentoo news letter, Hidden somewhere in the middle, assuming users read about the update. forums, As long as the activity of these topics last. first hits in Google, Nothing found when I search for things like gentoo systemd blocker. /topic of #gentoo at Freenode, MLs, pretty much everywhere. Which amounts to only a certain share of the users. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. Your reply doesn't answer the posed questions; instead, it demonstrates that it costs a lot more human resources the way we do things now. Users have to figure it out the hard way, developers then have to bring out the news the hard way; just like most of the previous times. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 8:24 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 15:08, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? IMHO, not every singular dependency change (even blocker) needs one. For those failing to read `eix upower` or `emerge -C upower` or masking systemd, or number of other ways the blocker can be solved, the answer is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at Freenode, MLs, pretty much everywhere. The whole point of news is to tell people about an action they need to take before they have to take it. The output of portage doesn't really tell you what is going on. The article in GMN doesn't provide clear instructions on what needs to be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well. But news item has been planned all along for when UPower 0.99.0 goes stable, propably GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to accumulate as news worthy. This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:04:23 -0400 Rich Freeman ri...@gentoo.org wrote: The whole point of news is to tell people about an action they need to take before they have to take it. The output of portage doesn't really tell you what is going on. Note that I'm not against a news item in the short term; what I am suggesting with mix-ins is even a step before that, but that's something only achievable in the long term and of course not now. So, yes, please write and send a news item out as soon as possible. The article in GMN doesn't provide clear instructions on what needs to be done, and refers to 0.99.0 when the issue impacts 0.9.23 as well. Besides that, a longer title would help; currently it reads to me like X update, which means that if I don't care about X or don't know X that I'm very likely to skip it. Mentioning systemd somewhere in there, as well as transition; could help with drawing attention to it. But given a news item, this GMN entry would become less important; regardless, it can help for those that manage to skip reading the item. This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in comparison, 0.99.0 mainly wants you to run it with systemd: 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/14 08:08 AM, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? That's easy -- we don't have a way to do vdb updates that will split a package, only move a package. And since this isn't a package move (as the original package still exists) we can't leverage that. otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. Technically we could do this via a systemd profile too -- ie, mask new upower everywhere but systemd profiles, and in systemd profile mask upower-pm-utils. However, that doesn't get around the actual need to - --unmerge upower and emerge upower-pm-utils (or hopefully just do the latter as a soft-block will do the unmerge?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlONzPEACgkQ2ugaI38ACPDI5AD/eEbk4156UrMNHmCPIA+xwNfe nlGC5pnZ3Zs0gu/88EAA/A9hNlNfGzhqorE+8cEz3lkTVuxxq8gv++7Ogm0zY8DU =I7Mw -END PGP SIGNATURE-
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 9:20 AM, Tom Wijsman tom...@gentoo.org wrote:
On Tue, 3 Jun 2014 09:04:23 -0400
Rich Freeman ri...@gentoo.org wrote:
This has already hit stable. The dependency on systemd is present in
sys-power/upower-0.9.23-r3, which was just stablized.
Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; in
comparison, 0.99.0 mainly wants you to run it with systemd:
From upower-0.9.23-r3.ebuild:
RDEPEND=${COMMON_DEPEND}
kernel_linux? (
app-shells/bash
=sys-apps/systemd-200
)
No use conditional there...
Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
I thought it had one, but maybe it is in another package I'm unaware of.
Did somebody stick the dependency in the wrong version? :)
Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:20, Tom Wijsman wrote: This has already hit stable. The dependency on systemd is present in sys-power/upower-0.9.23-r3, which was just stablized. Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. For example, I'm using Xfce, OpenRC, UPower 0.99.0, pm-utils, Xfce 4.11+ and I have hibernate/suspend working just fine without systemd. And UPower is for much more than hibernate/suspend, it has dozens of features, so anykind of systemd dependency on 0.99.0 wouldn't make sense 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:29:59 -0400 Rich Freeman ri...@gentoo.org wrote: No use conditional there... Yeah, I was a checkout behind; I'm clueless wrt the new revision bump. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:40, Tom Wijsman wrote: On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or other To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0 because they are going away, to indicate this is the best time to make informed decision and take manual action regarding choosing which features set he/she wants, to read up upstream announcements regarding UPower, to follow-up and do what admins do - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org wrote: To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. It just isn't obvious to users who haven't read GMN that there is a simple fix. Even users who do read GMN might get confused by the version number issue, as the change impacts stable users who aren't using the version of upower mentioned in GMN. Plus, GMN isn't in-your-face like portage news. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Jun 2014 09:26:09 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/14 08:08 AM, Tom Wijsman wrote: On Tue, 3 Jun 2014 07:35:42 -0400 Rich Freeman ri...@gentoo.org wrote: This probably could have used a news item, as the change impacts both stable and ~arch users. Are we going to write a news item every time systemd acquires a new mandatory relationship with a reverse dependency? They need to do an emerge -1 sys-power/upower-pm-utils to actually get the new package, But the user doesn't want systemd; so, then why does the user have to perform a manual step every time that systemd has an acquirement? That's easy -- we don't have a way to do vdb updates that will split a package, only move a package. And since this isn't a package move (as the original package still exists) we can't leverage that. - From the dependency viewpoint this isn't a package split or move, it is rather an introduction of || ( A B ) alternatives in the dependency chain. In this case, the first option (A) is tried and exhausted; this complexity results in other options (B) not being thoroughly considered. If you want Portage to make a transition to alternatives, you need to get a mask in place for the first option; so, we can leverage this: 1. || ( A B ) with A masked causes Portage to install B instead; 2. || ( A-0.99 B ) with =A-0.99 masked causes a downgrade to A-2. So, what misses here is that mask; which you could put in a mix-in. (In this specific case A is upower and B is upower-pm-utils.) otherwise portage is going to try to switch them from udev to systemd, There is the problem, the user doesn't want systemd; so, why is Portage (regardless of a systemd mask) trying to bring it to the user anyway? since packages like kdelibs list upower first, and portage has no way of knowing that this is a big change. And this is where you can make Portage smarter. http://www.funtoo.org/Flavors_and_Mix-ins We don't have to go through all this if you had a no-systemd mix-in, where you could simply make out the choices in favor of the user instead of having to document and announce them all over the place. That mix-in could do something like masking the new upower that depends on systemd; when doing so, no more blockers all over the place. Technically we could do this via a systemd profile too -- ie, mask new upower everywhere but systemd profiles, and in systemd profile mask upower-pm-utils. In doing so, you assume that non-systemd profiles are anti-systemd; however, that's not the case. Currently GNOME and KDE have systemd profiles; but, there are a lot of other desktop environments in the Portage tree that have support for systemd. So, this means we would have to go and create a profile for each desktop environment and within such profile yet another profile for systemd; this becomes somewhat tedious if you can cover all that in a mixin instead. You're going to need mixins at some point when it's not just systemd that is a specialization but something else as well; unless you want to create even more directories for the possible combinations: - gnome/somethingelse - gnome/systemd - gnome/systemd+somethingelse However, that doesn't get around the actual need to - --unmerge upower and emerge upower-pm-utils (or hopefully just do the latter as a soft-block will do the unmerge?) Portage does this for you if you mask upower and provide it with sufficient backtracking; so, there's no need to do this manually. More explicitly noted: An upower mask allows us to say that an upgrade should do `emerge -C upower` and `emerge upower-pm-utils`, in the case that there is || ( upower upower-pm-utils ) listed as a dependency. Unless you have selected upower on purpose; which would be a different case than the one we're discussing here, also giving different output as it'll point out that @selected brings in what (upower) has been masked. - -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTjdWXAAoJEPWZc8roOL/QTwAIAJeYIYpF4JIclsGY67ZHDpuM D2rY3JlCEof4iMcPGccR+lsiTWp0inRRkR5YYejPTMupD/MUqmhuxAogLcUE79m6 lBGQOmO9G4Iduvuoesa99x7UUW6Ihx9TrmoPmn++S9Bn8FrFq+52rUkRDFrlbsrP +wyrc2Dh8SQlI7Bf2r0WcloE9xb+TVXKeyJeZs9eN0afQXqtFJraoGuPYsj7yF7f JWHq26HWRBd+EM8Gyx0OHgPW4Uc7mwhabywxfh44HcjLvh5DN+4/fXbLXc6ytBvi Z5+4UMMXNEUloovKKHT45uVCJ159njFk9KW5SQhKRihaQD63USMm+sKGm0Kx0Ek= =Sugk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 09:53:45 -0400 Rich Freeman ri...@gentoo.org wrote: Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. Why is the mix-in not a simple solution? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, Jun 3, 2014 at 10:05 AM, Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 09:53:45 -0400 Rich Freeman ri...@gentoo.org wrote: Whatever - short of profiles/mix-ins or whatever you want to do on a big scale there isn't a simple solution to problems like this. Why is the mix-in not a simple solution? It involves a tree-level change. Granted, for something like systemd it probably makes sense. However, there are always going to be dependency resolution situations where the PM won't guess the user's intent. Maybe in these cases the PM should make it more clear that there was an alternative option. Rich
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 16:53, Rich Freeman wrote: On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org wrote: To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes It seems we are seeing the severity of something like this diffently, to me, this belongs to normal Portage functionality, I see something like this from other packages constantly, I don't understand why this package has suddently been highlighted like this It just seems to me people are up in the arms again re: seeing word systemd, when ironically all of this hassle was *for* OpenRC users, to ensure continuity for them in sys-power/upower-pm-utils where 0.9 git branch will continue to live If I hadn't stepped up and blocked the 0.99.0 keywording when it was originally about to happen, and then figured a migration path, and then stepped up with help from pacho2 and tomwij, and migrated the tree like this, we'd have everyone on 0.99.0 and no hibernate/suspend for anyone else except systemd users So, after all the effort we've put in and prepared the tree with OpenRC users specifically in mind, if people have to take one or two manual emerge commands themselfs, I'm totally fine with that, that's what Gentoo is all about, choices, and people who complain about it, really seem like ungrateful over anything else, and I'm disappointed. I keep expecting more from our users, the handholding has lately gone overboard I hope that didn't come out wrong, and it certainly wasn't a reply directly aimed at you, it was to the thread in general (I'm still with my original plan, when 0.99.0 goes stable, there will be multiple bulletin points to document, news item will be issued) - Samuli
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. And please keep such changes out of stable until proper documentation is in place (and the 30 day period has elapsed, etc.) Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. No, it wouldn't have, because 0.99.0 is the superior version to which we are all working towards and 1 would have superceded it And 0.99.0 is for both, systemd and openrc users
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
Samuli Suominen schrieb: On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. No, it wouldn't have, because 0.99.0 is the superior version to which we are all working towards and 1 would have superceded it And 0.99.0 is for both, systemd and openrc users sys-power/upower-1 would not install any files and be treecleaned some months after the transition is complete. upower-1.ebuild: DEPEND=systemd? ( sys-power/upower-systemd ) !systemd? ( sys-power/upower-pm-utils ) upower-pm-utils-0.9.23.ebuild: DEPEND=!sys-power/upower-1 !sys-power/upower-systemd upower-systemd-0.9.23-r3.ebuild: DEPEND=!sys-power/upower-1 sys-apps/systemd I will attach the proposed ebuilds to bug 512252. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. It requires an analysis on its own, among the kind of collecting bad non understandable output and the solution to it; then try to make up favorable output for it. After which it has to be seen if the needed information can be obtained, as well as the algorithms for that favorable output can be implemented. Somewhere in that flow we also need to have some kind of quality review cycle to see if the favorable output helps; otherwise, it could make the situation worse instead of better. Because, really, ... http://bpaste.net/raw/Pp9Iv18ehzzHKVbm4Sbe/ ... does not give away upower as a root blocker cause; even going further than that, it doesn't suggest upower-pm-utils as an alternative. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 16:52:30 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 3 Jun 2014 17:48:05 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. That isn't the issue... Developers need to stop being clever in expressing dependencies, and start giving the package mangler explicit information about what a dependency means. Relying upon heuristics to figure out what a complicated mess of || ( ) and blockers means just leads to things intermittently going horribly wrong. Which brings me back to the mix-in suggestion, which improves input. :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 03 Jun 2014 16:57:12 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Samuli Suominen schrieb: And 0.99.0 is for both, systemd and openrc users sys-power/upower-1 would not install any files and be treecleaned some months after the transition is complete. upower-1.ebuild: DEPEND=systemd? ( sys-power/upower-systemd ) !systemd? ( sys-power/upower-pm-utils ) Read Samuli's comment again, please; what you suggest introduces a problem for users, like me, that have 0.99 installed regardless of whether we are using OpenRC or systemd. Besides that, there is no need for a sys-power/upower-systemd package. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tue, 3 Jun 2014 17:48:05 +0200 Tom Wijsman tom...@gentoo.org wrote: On Tue, 3 Jun 2014 10:09:42 -0400 Rich Freeman ri...@gentoo.org wrote: Maybe in these cases the PM should make it more clear that there was an alternative option. Yes, Portage could also be helped out with some output improvements. That isn't the issue... Developers need to stop being clever in expressing dependencies, and start giving the package mangler explicit information about what a dependency means. Relying upon heuristics to figure out what a complicated mess of || ( ) and blockers means just leads to things intermittently going horribly wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tuesday, June 03, 2014 04:46:18 PM Samuli Suominen wrote: On 03/06/14 16:40, Tom Wijsman wrote: On Tue, 03 Jun 2014 16:28:47 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: On 03/06/14 16:20, Tom Wijsman wrote: Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag; No, it doesn't. Nevermind, `cvs up`-ed; heh, I don't understand how you've got to that change, I thought there only was a problem with 0.99.0? in comparison, 0.99.0 mainly wants you to run it with systemd: mainly, as in, since 0.99.0 removed support for hibenate/suspend in favour of systemd, the power/session managers need to integrate their own hibernate/suspend support diffently. Ah, right; thinking of MATE, I understand the 0.99.0 bit now. 26 May 2014; Samuli Suominen ssuomi...@gentoo.org upower-0.99.0.ebuild: This release is mainly for use with sys-apps/systemd because upstream removed support for sys-power/pm-utils completely from git master. The 0.9 branch is for sys-power/pm-utils use. Adjust ebuild accordingly. Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency; I thought it had one, but maybe it is in another package I'm unaware of. Outdated ChangeLog entry from March, those were the facts we dealt back then, only partly true anymore, consumers have evolved Which means that the situation I am assuming right now is outdated; so, if you don't mind feel free to highlight why 0.9.23-r3 needs systemd. To prevent OpenRC users from installing this version because it's an old UPower with no pm-utils support, with no hibernate/suspend support, to ensure desktops don't end up with greyed out Hibernate/Suspend buttons To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or other To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0 because they are going away, to indicate this is the best time to make informed decision and take manual action regarding choosing which features set he/she wants, to read up upstream announcements regarding UPower, to follow-up and do what admins do All this should have been in a news item, BEFORE it got stabilized. -- Joost
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Tuesday, June 03, 2014 04:45:36 PM Chí-Thanh Christopher Nguyễn wrote: Samuli Suominen schrieb: On 03/06/14 16:53, Rich Freeman wrote: So, I get why you did it, but my concern is that when you tell portage that non-systemd users shouldn't use this package, portage helpfully solves that problem by turning all the non-systemd users into systemd users, instead of switching them to the alternative that works without systemd. Portage doesn't do anything on it's own, surely it needs an admin to accept or reject the changes I disagree. It would have been straightforward to create a transitional package sys-power/upower-1 which makes openrc users transition to sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd or something similar. And please keep such changes out of stable until proper documentation is in place (and the 30 day period has elapsed, etc.) +1
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...)
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. Mix-ins from Funtoo, anyone? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/04/2014 08:24 AM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: On 06/03/2014 07:25 PM, Samuli Suominen wrote: On 03/06/14 14:40, J. Roeleveld wrote: Would have been nice to fix all the dependencies BEFORE marking the systemd- depending sys-power/upower-pm-utils stable. -- Joost No clue what you mean, sys-power/upower-pm-utils doesn't depend on sys-apps/systemd, and whole Portage tree is converted to proper dependencies and the conversion went in the correct steps. The only step missing is: Mask the new version on all non-systemd profiles so that portage doesn't try to install it (I wonder why systemd and the related stuff isn't masked on non-systemd profiles anyway ...) There is no such thing as a non-systemd profile; a sub directory is a specialization, that doesn't mean that it parents suddenly become the opposite of that. No, the parents are just generalizations that aren't as specific as the sub directory. Since systemd needs special profiles to be easy to use ... ... it'd be the boring and easy way to restrict it to those profiles so that dependency changes don't cause this needless amount of work for users, and this indecent amount of mail on this mailinglist Doing what you've suggested everywhere but in gnome/systemd and kde/systemd is a recipe to upset everyone whom runs systemd on another desktop environment than GNOME or KDE; so, that's not a way forward. I have no idea what you are trying to say, but there's a desktop profile Another option is to create no-systemd sub directories; but such profiles will be highly controversial, besides helping the exponential grow of the profiles directories as well as be a non-default profile. The default is already that, all I'm suggesting is masking systemd there so that portage doesn't needlessly antagonize users Mix-ins from Funtoo, anyone? No thanks
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 06/03/2014 08:24 PM, Tom Wijsman wrote: On Wed, 04 Jun 2014 07:55:50 +0800 Patrick Lauer patr...@gentoo.org wrote: [Lots of comments about upower updates and interactions between systemd and Open-rc...] I'm sorry, but it seems to me that this is *another* power grab by the systemd Cabal. More and more a small group of developers are making non-well-thought-out changes to the Linux environment that have the effect of pushing systemd as the default model for init systems. First, they abrogated the FHS by putting boot necessary stuff in the /usr hierarchy (deliberately ignoring the FHS rationale and history) forcing many users to redo systems to not have separate /usr trees. Then, they steal a general kernel command line parameter (debug) that makes booting impossible in certain cases. (Linus had to put his foot down on that one.) And now, another useful process is forced to make workarounds for users so that they don't get switched to systemd willy-nilly. (Don't get me started on the GD linkage between Gnome and systemd!) As one of the uncredited makers of the SysV init system (I was a lowly consultant sysadmin during the Unix System IV roll out) I know more of the history than most. SysV init punted the hard problem of getting sequencing and dependency during startup to the more agile mind of a human because we didn't have the time to develop a general dependency solver for the boot sequence. (And someone who was supposed to document that need for examination in the SysV development cycle seems ti have neglected the item.) OpenRC does some logical and straight-forward extensions to the SysV paradigm and handles the problem well enough. SystemD goes for a total rewrite (and suffers second system syndrome) and seems to be masterminded by folks with Napoleonic ideation. Mind you, I am *not* anti-systemd. In many ways it is a good system that automates a lot of stuff that needed automation. I just have some strong disagreements with some of the choices its implementors and advocates have made in relation to other aspects of system management. I have thought that Linux and the FOSS movement was about user choice. Not a small band of folks deciding that users shouldn't be expected to know what their systems are doing under-the-hood and forcing that vision on everyone, whether they want it or not. I moved to Gentoo (from a long history with RedHat and then Fedora) because it seemed to me that the concept of maximum choice was a treasured and honored position. Recent events, however, seem to indicate that even here in Gentoo-land there is a power struggle occurring. As I'm getting to the stage of being a senior citizen I probably will not have to deal with the fallout of this struggle for too long, but it disheartens me to see it occurring.
Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore
On 31/05/14 05:47, Steven J. Long wrote: On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote: On 27/05/14 08:34, Michał Górny wrote: Dnia 2014-05-26, o godz. 23:15:34 Samuli Suominen ssuomi...@gentoo.org napisał(a): UPower upstream removed sys-power/pm-utils support from 0.99 release (currently unkeyworded in tree), as in, from current git master. Don't worry. Looking at the past, I can guess this is only a temporary inconvenience. I'm pretty sure upower will be discontinued soon and replaced with systemd-powerd or something :D. That's more or less what they already did, they forced eg. xfce4-power-manager upstream to move the deleted pm-utils code from upower directly to the power manager (application) itself, likewise for xfce4-session Which means applications will now need to duplicate the pm-utils related code per application basis So I expect upower to be more or less dead for everything but systemd users, except for those upstreams that will actually follow the Xfce path and do the duplication Yet, still, small portition of the code is still 'generic', so xfce4-power-manager will still need both, upower, even 0.99, and then pm-utils, depending on the version, codepath is selected This was sort of expected, since pm-utils has been abandoned for ~5 years now at upstream, so nobody is maintaining non-systemd related power management tools anymore, and falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be necessary again, it's like going back to 90s for non-systemd users :P I can't believe I'm reading that from a distro-developer. Basically this entire thread is systemd is deprecating the existing tools, so let's dump them and half our userbase back to the 90s, isn't that a great thing? Then you misunderstood. Notice the :P as an indicator of sarcasm. I've already created sys-power/upower-pm-utils where the sys-power/pm-utils 0.9 git branch will continue to live.
