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