[gentoo-dev] Re: Changing order of default virtual/udev provider

[Duncan]

Daniel Campbell posted on Tue, 09 Feb 2016 06:44:34 -0800 as excerpted:

> If anything, a developer will have more control over how their daemon
> is handled in the rc script. They would have to read systemd's C code
> or its plethora of unit options to set it up 'just right' to achieve
> the same.

FWIW, that's an unfortunately common misconception.

It's just as easy to setup a shell script to do the work in systemd as it 
is in rc-based systems.  After all, at a high level it's simply another 
executable, and at an equally high level, setting up executables to run 
automatically at system start or other major system status change event 
is what init systems, regardless of the specifics, /do/.

And in fact, that's pretty much what I've done here for a variety of 
custom services, using native systemd options and functionality where it 
makes sense, scripting my own where I haven't found shipped functionality 
or services that do exactly what I want.

And I don't claim to be a C coder so I've certainly not had to read that 
to do it.  While I've used systemd unit options where they make sense 
because they're generally well documented and do what it says on the tin, 
if I'd considered rescripting that functionality easier than reading the 
friendly documentation, I certainly could have done so.

Meanwhile, arguably, "more control over how their daemon is handled" is 
incorrect as well, when with systemd it's trivial to setup cgroup control 
over anything cgroups control, and there's tools like nspawn if needed, 
that allow _way_ more control than chroot and the like, with similar 
levels of pre-configuration necessary.


But that's beside the point of the original thread.  I disagree with Rich 
here, because while (like him) I'm a systemd convert myself, I'm strongly 
in support of keeping it optional, and on profiles where systemd isn't 
the default, it simply makes no sense to me to default to a device 
manager that strongly discourages that sort of usage and has said that 
future breakage is a matter of when, not if, when there's a similarly 
functional and currently drop-in-replacement device manager that 
explicitly supports the use-case in question.

If it applied to systemd profiles, the question of an appropriate default 
and its resolution would arguably be far different, but the fact of the 
matter is it doesn't, we're talking about non-systemd profiles 
exclusively, and their default openrc use-case is strongly discouraged by 
udev's systemd upstream, so it simply makes sense to choose defaults 
where the upstreams aren't rabid enemies.

My major remaining concern is, as I've already said, documentation.  If 
that can be resolved, the case is clear enough, and even if not, it's 
simply a judgment call on which negative is less bad, lack of 
documentation, or an upstream that's actively opposing our use-case and 
has clearly stated that breakage is a matter of when, not if.
-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman