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 |