Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Systemd upower
Date: Tue, 03 Jun 2014 23:04:55
Message-Id: 538E5460.6000503@gmail.com
In Reply to: Re: [gentoo-user] Systemd upower by Alon Bar-Lev
1 On 04/06/2014 00:06, Alon Bar-Lev wrote:
2 > On Wed, Jun 4, 2014 at 12:59 AM, Canek Peláez Valdés <caneko@×××××.com> wrote:
3 >>
4 >> On Tue, Jun 3, 2014 at 4:40 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
5 >> [...]
6 >>> Incidentally, what exactly is wrong with systemd writing a dhcp server &
7 >>> client, and an ntp client? Is that project prohibited from writing such
8 >>> software? Are they not allowed to do it? Does it break legal laws? Is
9 >>> there an NDA or non-compete clause in the mix that I'm not aware of?
10 >>> Because they are the only things that could stop systemd from writing
11 >>> such code; without such prohibitions they are free to spend their time
12 >>> doing whatever they damn well please and if that means yet another dhcp
13 >>> implementation, so be it.
14 >>
15 >> Alan, thanks for succinctly putting why is absurd to complain about
16 >> someone else's desire to write whatever code she desires to write. And
17 >> to sharing it to the world! The HORROR!
18 >>
19 >> How *DARE* they to release their code? For free!
20 >>
21 >
22 > Once again, you do not understand the claim.
23 >
24 > If a user of Gentoo chooses to use non systemd profile, it means that
25 > we need to make sure systemd will not be a valid option, ever.
26 >
27 > In this case, if it is to disable the upower USE flag, or to provide
28 > alternative, block newer version, whatever make it possible to have a
29 > system working without systemd.
30 >
31 > systemd should not be visible at any time, nor its implications.
32 >
33 > Alon
34
35
36 Alon,
37
38 You need to read the massive thread on -dev about this and understand
39 the technical reason why portage is doing something strange.
40
41 I'm not going to give you opinion or rant here, I'm going to give you fact:
42
43 Nobody is shoving systemd down anyone's throat because that is not what
44 the portage code did. UPower removed their support for pm-utils
45 (unmaintained for 5 years) and now support that same functionality
46 provided by systems. UPower has the right to make that call.
47
48 Samuli picked up that this is an issue for non-systemd users - they will
49 not have the ability to suspend/hiberate. So a package was created
50 called upower-pm-utils which contains the pm-utils code prior to the
51 UPower change. If you want UPower to work as it always did for you,
52 simply unmerge upower and merge upower-pm-utils. To have
53 suspend/hibernate done the systmed way, just leave UPower installed and
54 let portage do it's thing.
55
56 Now, this is where the snag comes in. Portage sees you have UPower and
57 you now need pm functionality, and portage needs to merge something to
58 fill that dependency. Because of the way the code works, portage finds
59 UPower+systemd first always, and decides to use that. It's software, not
60 a human, so it doesn't question your decision and proceeds. It's
61 analogous to having a virtual - if you don't tell portage which one to
62 use, it picks the first. You tell portage which one you want by
63 installing it, and portage is happy with that.
64
65 Should there have been some USE flag-type solution to definitely
66 indicate your choice? Sounds good in practice but in this case it's not
67 a good idea (see the -dev thread for reasons why). Besides, this is a
68 transitional phase and things will change again in a month. It's really
69 not worth the effort to set up a USE for one package for a month.
70
71 Those are the facts as laid out by our Gentoo devs and those facts do
72 not support a conspiracy theory.
73
74 Summary;
75
76 You yourself do not want systemd. OK. Here's how to not get it in this case:
77
78 emerge -C upower && emerge -1 upower-pm-utils
79
80
81
82
83
84 --
85 Alan McKinnon
86 alan.mckinnon@×××××.com