warning

[Cb]

> On Nov 27, 2013, at 11:07 AM, Tom Evans <tevans.uk at googlemail.com> wrote:
> 
>> On Wed, Nov 27, 2013 at 4:55 PM, Ajtim <lumiwa at gmail.com> wrote:
>> OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov  3 19:43:01 UTC 2013     root at snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>> 
>> When I boot a computer I got one warning:
>> 
>> /etc/rc: WARNING: $tcsd_enable is not set properly
> 
> 
> This is part of a port, security/trousers. Reinstall it?
> 
> Cheers
> 
> Tom

There are more than a few ports in the tree right now that are causing warnings just like that one to be emitted. (I didn't check security/trousers to see if what I describe below is actually it's crime. It is likely that this is applicable in your particular case with trousers.)

It gets emitted by rc(.subr) when a port has an rc.d file (that is, one that leverages rc.subr,) but it fails to supply it's own default for that variable (which should almost invariably be a "NO").

Somewhere in the rc.d file for foo, before calling load_rc_config, is supposed to be a line similar to this:

: ${foo_enable:="NO"}

At least, that's how I've been doing it and how I understood things. Please correct me if there's a more orthodox way.

samba_enable and dbus_enable warnings pop into mind, among others, (though I'm speaking off the top of my head, I've not verified those currenty, and they may have been fixed in the last couple weeks).

These warning emissions should ideally all be cleaned up throughout the tree. I guess porters more typically test their ports enabled and forget to notice that things are getting a little noisier when they are being left dormant.

There is a reason that rc.subr complains about an undefined master on/off switch for a port instead of quietly assuming "NO". In theory, it is up to the port-roller since there is an atypical possibility that by just having a package installed, it might indeed be a good idea to default to its complete or partial activation during startup _without_ the end-user explicitly enabling it. Someone pipe up if their port exhibits such behavior and they feel it justified because I'd like to know, not to attack the choice, rather to expand my view. I can think of no such instance, but I understand the theory behind the liberty and thus why rc.subr wants to enforce the responsibility of defining the default.

When wearing my user hat, I've typically ignored such errors to no ill effect, as the lack of a variable obviously implies checkyesno will exit 1 (i.e. return "NO"). I, for one, have a lot more ports installed than are enabled on most of my systems because developers like when things are just ready to go for them. I also subscribe to the philosophy that one ought to be able to install a thousand packages and have nothing else magical happen until one implicitly enables what they want to use. (Yet I appreciate, rather than fear, a little magic where applicable. Muahaha! Thus why I'm open to hearing anyone's thoughts if they default a port of theirs to do anything at all during startup without an explicit enable, even though my imagination currently offers me no such picture.)