OPTIONS, LATEST_LINK, and RCng

[Timur I. Bakeyev]

On Tue, 24 Feb 2004 13:19:42 -0500
  Charles Swiger <cswiger at mac.com> wrote:
>On Feb 24, 2004, at 11:15 AM, Timur I. Bakeyev wrote:
>> On Tue, 24 Feb 2004 10:46:24 +0100
>>  Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:
>>> Chuck Swiger wrote:
>>>> I that life would be better, or less astonishing :-), if 
>>>>rcvar 
>>>> defaulted to "y" for manual invocation and for startup 
>>>>scripts in 
>>>> /usr/local/etc/rc.d...
>>>
>>> I guess I don't really like that. First of all, I'm a 
>>>big friend of 
>>> manually
>>> activated services, since then I know what is running on 
>>>my machine. 
>>> Second
>>> it would be difficult to make this consistent, since I 
>>>might only 
>>> want to
>>> start some of the daemons provided in a port (eg. slapd 
>>>but not 
>>> slurpd from
>>> OpenLDAP). Most of the `classical' script defaulted to 
>>>`NO' (or 
>>> .sample).
>>> But maybe I'm too cautious here?
>>
>> I really don't understand, what this arguing is all 
>>about :(
>
>I don't think Oliver and I are arguing, or even 
>vigorously disagreeing.  :-)

>I'm willing to live with foo_enable defaulting to NO 
>under rcNG all of the time-- after all, the patch I 
>suggested doesn't change that behavior.  However, I will 
>make the argument that foo_enable really ought to default 
>to YES when the command is run interactively.  Failing 
>that, at the very least rcNG needs to tell the user that 
>the command they just ran didn't actually do what they 
>expected, which is what my patch does.
>
>[ I'd also prefer to see rcNG default to NO for services 
>shipped with the base system, and YES for services added 
>by the user via ports-- aka services in 
>/usr/local/etc/rc.d-- but I can live with the existing 
>behavior (as I said, sorry for the repetition :-). ]

Seems, I've read it in a bit different way. I completelly 
agree with the last statement :) Notifying user in such 
cases is "good thing (tm)". Sorry for ranting :)

With regards,
Timur