Re: On possibly "finer" dependencies in s6-rc

From: Casper Ti. Vector <caspervector_at_gmail.com>
Date: Tue, 29 Sep 2015 22:28:30 +0800

I see. I agree that the typical use case of this feature is almost
limited to the `eth0'/`wlan0' scenario and cannot think of any other
concrete use case that is compelling.

Nevertheless, I still think this make s6-rc "incomplete"
mechanism-wise (sorry if that appears like insulting): opportunist
dependencies support can be implemented using a preprocessor, without
requiring unreasonable hacks or incurring any feature loss; on the
other hand, as a mechanism, the online virtual is demanding to implement
in an RC system, but might be even much more difficult to implement
elsewhere. More than that, this mechanism fits naturally into an RC
system, so it is architecturally a reasonable part of s6-rc.

Risking the possibility of being regarded as insulting, I respectfully
say that your way of `eth0'/`wlan0' switching is a choice of policy,
which does not make up for the incompleteness in the set of mechanism
provided by s6-rc.

Sorry again for my possibly irritating language. Hope these make sense.

On Tue, Sep 29, 2015 at 03:45:41PM +0200, Laurent Bercot wrote:
> That kind of dependency is still infrequent compared to "normal"
> dependencies; I don't think it's unreasonable to maintain a set of
> compiled databases to address that case. The size of the set may
> grow exponentially, but if it becomes larger than 4 or 8 databases,
> I tend to think it's an abuse of virtual dependencies; I can be
> convinced otherwise with a real-world example that cannot be solved
> another way.
>
> Having several compiled databases and switching between them with
> s6-rc-update is normal procedure. I worked on s6-rc-update for a long
> time to make sure that this procedure would be as painless as possible,
> even if it has to be done on a semi-regular basis. Switching between
> eth0 and wlan0 is a typical case of this, and as a matter of fact,
> it's *exactly* what I'm doing on my home router. :)

-- 
My current OpenPGP key:
4096R/0xE18262B5D9BF213A (expires: 2017.1.1)
D69C 1828 2BF2 755D C383 D7B2 E182 62B5 D9BF 213A
Received on Tue Sep 29 2015 - 14:28:30 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC