Gentoo Archives: gentoo-amd64

From: Mark Knecht <markknecht@×××××.com>
To: Gentoo AMD64 <gentoo-amd64@l.g.o>
Subject: Re: [gentoo-amd64] Re: amd64 list, still useful? Was: btrfs
Date: Thu, 05 Jun 2014 18:59:28
Message-Id: CAK2H+eff_N8GzHnLWYNXA4nDQGuXGSyFyOptgFuUZfE5wV7UFA@mail.gmail.com
In Reply to: [gentoo-amd64] Re: amd64 list, still useful? Was: btrfs by Duncan <1i5t5.duncan@cox.net>
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

Replies

Subject Author
[gentoo-amd64] Re: amd64 list, still useful? Was: btrfs Duncan <1i5t5.duncan@×××.net>