1 |
On Wed, Jun 4, 2014 at 7:00 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> Mark Knecht posted on Wed, 04 Jun 2014 09:41:30 -0700 as excerpted: |
3 |
> |
4 |
>> There is an in progress, higher energy thread on gentoo-user with folks |
5 |
>> getting upset (my interpretation) about systemd and support for |
6 |
>> suspend/resume features. I only found it being that I ran into an emerge |
7 |
>> block and went looking for a solution. (In my case it was -upower as a |
8 |
>> new use flag setting.) |
9 |
> |
10 |
> Yeah. I saw the original dev-list thread on the topic, before it all hit |
11 |
> the tree (and continuing now), which is a big part of why I subscribe to |
12 |
> the dev-list, to get heads-up about things like that. |
13 |
> |
14 |
|
15 |
Maybe all Gentoo users should subscribe! Over time we would likely |
16 |
all get a bit smarter. ;-) ;-) ;-) |
17 |
|
18 |
> What happened from the dev-list perspective is that after upower dropped |
19 |
> about half the original package as systemd replaced that functionality, |
20 |
> the gentoo maintainers split the package in half, the still included |
21 |
> functionality under the original upower name, with the dropped portion in |
22 |
> a new, basically-gentoo-as-upstream, package, upower-pm-utils. |
23 |
> |
24 |
|
25 |
I certainly have no issue with the basics of what they did, but more |
26 |
in a second. |
27 |
|
28 |
> But to the gentoo maintainer the portage output was sufficient that |
29 |
> between emerge --pretend --tree --unordered-display and eix upower, what |
30 |
> was needed was self-evident, so he didn't judge a news item necessary. |
31 |
> What a lot of other users (including me) AND devs are telling him is that |
32 |
> he's apparently too close to the problem to see that it's not as obvious |
33 |
> as he thinks, and a news item really is necessary. |
34 |
> |
35 |
|
36 |
Yeah, this was likely the issue. One comment in the -user thread on this |
37 |
subject was that at least one -dev-type thinks users should be reading |
38 |
change logs to figure this stuff out. I no longer remember how long I've |
39 |
run Gentoo but it's well beyond a decade at this point. Daniel Robbins |
40 |
was certainly participating. I was working at a company from mid-1999 |
41 |
to 2004 when I started. I can only say that I've never read a change log |
42 |
in that whole time. |
43 |
|
44 |
> Compounding the problem for users is that few users actually pulled in |
45 |
> upower on their own and don't really know or care about it -- it's pulled |
46 |
> in due to default desktop-profile use-flags as it's the way most desktops |
47 |
> handle suspend/hibernate. |
48 |
|
49 |
As is the case for me using kde-meta. However while I figured out I could |
50 |
set -upower on kdelibs and not have any build or boot issues pretty quickly |
51 |
I soon discovered that flag goes beyond my simplistic view of |
52 |
suspend/resume which I have never used. It also covers _everything_ in |
53 |
the Power Management section of systemsettings which means I lost |
54 |
my ability in KDE to control what I suspect is DPMI time settings on |
55 |
my monitors. I'll either have to learn how to do that outside of KDE or |
56 |
reinstall the newer upower-pm-utils package. |
57 |
|
58 |
> Further, certain desktop dependencies |
59 |
> apparently got default-order reversed on the alternative-deps, so portage |
60 |
> tries to fill the dep with systemd instead of the other package. |
61 |
> Unfortunately that's turning everybody's world upside down, as suddenly |
62 |
> portage wants to pull in systemd *AND* there's all these blockers! |
63 |
> |
64 |
|
65 |
Yeah, that's what got me to look at gentoo-user and find the problem. Lots |
66 |
of blocks involving systemd. |
67 |
|
68 |
<SNIP> |
69 |
> So things should really be simmering back down pretty shortly. =:^) |
70 |
> Meanwhile, in the larger perspective of things, it's just a relatively |
71 |
> minor goof that as usual is fixed in a couple days. No big deal, except |
72 |
> that /this/ goof happens to include the uber-lightening-rod-package that |
73 |
> is systemd. Be that as it may, the world isn't ending, and the problem |
74 |
> is indeed still fixed up within a couple days, as usual, with |
75 |
> information, some reliable, some not so reliable, available via the usual |
76 |
> channels for those who don't want to wait. |
77 |
> |
78 |
|
79 |
This stuff does happen once in awhile. I'm surprised it doesn't happen |
80 |
more often actually so for the most part the release process is pretty |
81 |
good. |
82 |
|
83 |
WRT to systemd, my real problem with this latest issue is the systemd |
84 |
profile issue, and beyond that there doesn't seem to be a systemd |
85 |
oriented new machine install document. In my study getting ready to |
86 |
build a new RAID (probably will be 2-drive 3TB RAID1) I wondered |
87 |
of I should give in to this portage pressure and go systemd. When |
88 |
I start looking there all I find are documents that seem to assume |
89 |
a pretty high understanding of systemd which doesn't represent |
90 |
my current education or abilities. Seems to me if the gentoo-devs |
91 |
interested in seeing systemd gain traction were serious this would be |
92 |
a high priority job. All we get today is |
93 |
|
94 |
http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap12 |
95 |
|
96 |
which to me says it's not what Gentoo developers want Gentoo users to |
97 |
use. Of course, that's just me. |
98 |
|
99 |
Take care, |
100 |
Mark |