Re: [gentoo-dev] rfc: openrc service script dependency checker

[Rich Freeman]

On Thu, Dec 4, 2014 at 12:14 PM, Dmitry Yu Okunev <dyokunev@××××××××.ru> wrote:
>
> I think almost everybody here agree that Detector is really required in
> OpenRC. It's quite definitely that sysadmin should be able to see any
> error situation on his/her machine.

No argument at all with this.

> I can understand that you
> don't care about Debian and I'm prepared to the
> unfortunate fact that we will have to maintain extra patch for OpenRC
> package in Debian.

Please understand that I have no concerns at all with changes that
make OpenRC and make it more useful for everybody, including
non-Gentoo users.

I just think we need to be careful about tolerating incorrect input,
simply because some users don't want to correctly provide input.

>
> On 12/04/2014 04:59 PM, Rich Freeman wrote:
>> I think that on a boot phase in case of parallel boot rc should try
>> to check if loop exists and it is then print a warning and switch to
>> a sequential boot.

Just for the record, I didn't write this.  :)

>
>> Just fix your dependencies.
>
> There's no dependencies to fix. They are already right. But OpenRC
> couldn't interpret them right. And I think Debian team won't "fix" their
> dependencies tree through all packages with init-scripts forcing
> themselves into scopes of every existing init/rc. Using other words,
> you're suggesting impossible thing. Sorry, but it sounds just like "get
> out of here" without any explanation. =\

A dependency that amounts to "this needs to be last" for more than one
service is an error.  You can make the system do something other than
make every one of them last, but that doesn't mean that you're
satisfying the dependency.

Something either needs something else or it doesn't.

Whether the Debian team is willing to fix these kinds of errors isn't
something I have control over.  If Gentoo package maintainers were
doing this sort of thing I suspect that QA would be getting involved.

I can't imagine that this sort of thing won't become just as much of a
problem with systemd.  If you have a dependency-based service manager,
you need to correctly specify your dependencies.  Systemd does use
targets which do make it easier to manage dependencies, and that is
something that could be done in openrc just as easily using dummy
services (they're really just virtuals - have a service that
starts/stops without actually starting/stopping anything which is
trivial in openrc since it is all just bash and openrc doesn't care
about processes).

Please don't get me wrong - I think this discussion is healthy and I'm
not saying "over my dead body" or anything like that.  I just want to
make sure that we're thinking about the best possible solution.  If
the current syntax limits our ability to properly specify dependencies
I'm all for improving it.  I just would rather see a clean and
deterministic solution rather than a workaround that tries to guess
how to handle a loop.  I'm all for input as to how to make life easier
for other distros to use OpenRC - it was always intended to be the
universal service starting solution from the beginning, hence the
name.  The fact that potential adoption within other distros is
exposing weaknesses in the dependency specification is a good thing -
we can improve it.

Honestly, I'm not convinced that any solution (openrc, systemd, etc)
really has a clean solution for the "this service may or may not need
this other service depending on how it is being used" situation.  In
many cases we're putting a "wants" vs a "needs" specification
(whatever the syntax) at the distro level and relying on the user to
either override this or manually enable services and so on.

--
Rich