On Tue, Sep 29, 2015 at 10:46:02AM +0800, Casper Ti. Vector wrote:
> * "opportunist" dependencies:
After some more thought, I found one may as well supply a `mandatory'
and `opportunist' file for each service, and write a preprocessor
program to auto-generate the `dependencies' file, like this
On Tue, Sep 29, 2015 at 09:29:23PM +0800, Casper Ti. Vector wrote:
> tr -s ' ' '\n' | grep -xF "$2" | cat "$1" -
Should be:
tr -s ' ' '\n' | grep -xFf "$2" | cat "$1" -
--
My current OpenPGP key:
4096R/0xE18262B5D9BF213A (expires: 2017.1.1)
D69C 1828 2BF2 755D C383 D7B2 E182 62B5 D9BF 213A
On 29/09/2015 04:46, Casper Ti. Vector wrote:
Nevertheless, I think it can be helpful to also support "opportunist"
dependencies: if said service is not enabled, it is silently ignored;
if said service is enabled, the dependency on it is considered in the
dependency resolution
Sorry, but please allow me to append my previously forgotten conclusion:
"Make it simple, but not over-simple".
On Tue, Sep 29, 2015 at 10:28:30PM +0800, Casper Ti. Vector wrote:
> Sorry again for my possibly irritating language. Hope these make sense.
--
My current OpenPGP key:
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):
On 29/09/2015 16:28, Casper Ti. Vector wrote:
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
[Just accidentally sent as private mail; reposting verbatim.]
I'm glad that possibility still exists. Thanks :)
On Tue, Sep 29, 2015 at 06:00:40PM +0200, Laurent Bercot wrote:
> I just compromised here in the name of practicality. It's definitely
> a possibility of evolution for s6-rc if it
