1 |
On 02/16/2016 08:33 PM, Michał Górny wrote: |
2 |
> On Tue, 16 Feb 2016 20:14:03 +0100 |
3 |
> Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote: |
4 |
> |
5 |
>> Alexis Ballier schrieb: |
6 |
>>> I also fail to see how udev using a new linux ipc would make it require |
7 |
>>> systemd. Quoting Lennart: |
8 |
>>> "You need the userspace code to set up the bus and its policy and handle |
9 |
>>> activation. That's not a trivial task. For us, that's what sytemd does |
10 |
>>> in PID 1. You'd need to come up with an alternative for that." |
11 |
>>> |
12 |
>>> If it's just that, it's not limited to udev, but anything using |
13 |
>>> kdbus/bus1, and would mean openrc/${favorite init system} will have to |
14 |
>>> do the same thing anyway. But again, almost 2 years is extremely |
15 |
>>> old considering all the flux that has been around kbus. |
16 |
>> OpenRC itself can for now just ignore kdbus, bus1, or whatever kernel |
17 |
>> IPC system comes next. But if upstream udev makes use of the systemd |
18 |
>> userspace interface to the kernel IPC system, then OpenRC would have to |
19 |
>> implement the same interface in order to have working udev. |
20 |
>> |
21 |
>> Also given the close relationship between systemd and udev, there is no |
22 |
>> guarantee that supporting other users of kdbus/bus1 will make udev |
23 |
>> automagically work. As these two are released together, there is no |
24 |
>> reason to have a stable, public API between them. |
25 |
> This all is going into some bickering nonsense and noise made by |
26 |
> systemd haters just to feed their troll, FUD and whatever else they |
27 |
> made around here. |
28 |
You call it hate, I call it having a choice. |
29 |
If I didn't want a choice I'd be using MacOS anyway, so please don't |
30 |
claim to understand my motivations (and why they are obviously wrong, |
31 |
since you know The Truth) |
32 |
|
33 |
> |
34 |
> So, yes, we should definitely switch to semi-maintained, |
35 |
> semi-documented fork made plainly of systemd hate. |
36 |
You mean sys-fs/udev ? I'd say unsupported instead of semi-maintained ;) |
37 |
|
38 |
> Because certainly |
39 |
> project that is created plainly for political reasons is better. |
40 |
> Because it will certainly be technically better if people have to focus |
41 |
> on copying regular udev maintainers and reworking their changes to keep |
42 |
> them working on forked codebase. |
43 |
> |
44 |
> And after all, as someone said, this will give eudev proper testing. |
45 |
(1) It's already used by lots of people |
46 |
(2) 'proper' testing? As opposed to be the default in more than a dozen |
47 |
distros that have usecases you and I rarely think of? |
48 |
> Because why default to something tested and working when you can throw |
49 |
> your random fork on our users. After all, if we force them to use it, |
50 |
> they will eventually start co-maintaining it, and it will no longer be |
51 |
> semi-maintained! |
52 |
> |
53 |
I have no idea why you think eudev is so horrible, but you're entitled |
54 |
to having opinions. |
55 |
|
56 |
And we don't throw it on our users more than we do now: If you don't |
57 |
like it just remove it. emerge -C is easy! |
58 |
You make it sound like we're removing choice, which is just ... how the |
59 |
... what are you?!? |
60 |
|
61 |
The whole discussion, which seems to turn everyone into a raging |
62 |
squirrel, is about changing the default provider of a virtual. All other |
63 |
providers will continue being listed and available. The change affects |
64 |
none of the current userbase (who seem to have a preference for eudev if |
65 |
forums polls have any meaning). |
66 |
|
67 |
The change will only affect the default selected when no udev provider |
68 |
is already installed. This would finally allow releng to have eudev on |
69 |
stage3, which so far they were unable to do without manually overriding |
70 |
defaults. |
71 |
|
72 |
^^ That is pretty much all that changes. Seriously. |
73 |
|
74 |
|
75 |
I have no idea why this topic that doesn't even affect the most vocal |
76 |
neigh-sayers in this discussion seems to be so insanely difficult ... |