[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd

[Duncan]

Austin English posted on Thu, 28 Sep 2017 16:27:31 -0500 as excerpted:

> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
>  * service: service `foo' does not exist
>
> Since `systemctl restart foo` works, I had a workaround anyway.
>
> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I can
> tell, most distros ship a service tool for all supported init systems.
> I.e.,
> Debian/Ubuntu: supports sysvinit and systemd via init-system-helpers
> CentOS/Fedora: provides support for systemd via initscripts
> OpenSUSE: has a working service binary for systemd (according to #suse)
>
> I'd like to propose moving `service` out of OpenRC and into a separate
> package that OpenRC and systemd can both use. It's very possible that we
> could simply package/use another distro's scripts (I haven't evaluated
> that though).

While I wouldn't oppose moving "service" into a separate package, I don't 
see the need.

It's rather like instructions assuming you're running MS something or 
other.  You simply translate them in your head to whatever's appropriate 
for your system-administrative environment and go on.  If you're bothered 
enough about it, when you're done, you open a support ticket with whoever 
wrote the instructions and suggest that they don't assume what cannot be 
taken as a safe assumption.  Otherwise, you just go on with your day.

While I can see users of some distros needing hand-holding in that 
regard, Gentoo has always been about giving people the tools, documenting 
how to use them, and getting out of the way -- if they can't read the 
docs or choose to use the tools to bash their hand, or /accidentally/ 
bash their hand because they couldn't be bothered to read the docs and 
either ran the tool without asking for confirmation (emerge without --ask 
or --pretend, we don't make --ask the default and have a --justdoit 
option, do you suggest we switch that around too?), or answered the 
tool's prompt for confirmation with a go ahead, well, that's their 
problem, and gentoo doesn't normally stand in the way of them bashing 
their hand... or head or whatever else, if they wish to do so.

So I don't see the problem.  As a systemd user I know that services are 
handled via systemctl, and would automatically translate an instruction 
to run "service" accordingly, just as when I was an openrc user I was 
aware that openrc didn't always function quite like other initsystems, 
and would consider what I was doing before I blindly ran "service 
<anything>".

Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and 
cgdisk, and who knows how many other binaries, with "safe" alternatives, 
because some gentooer couldn't be bothered to think for a moment whether 
a command in some instructions they're following is actually appropriate 
to the situation and the environment they're working in?

Meanwhile:

$ equery b service
 * Searching for service ... 

$

But that's no problem, because as I said I'd automatically translate the 
instructions into something appropriate to my environment.  (Indeed, were 
there a separate package providing "service" that was for some reason a 
dep, I'd strongly consider creating for myself an empty virtual to 
provide it, just as I've done for a number of other packages that aren't 
actually required to build or run the commands I /do/ want to run.)

-- 
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