> On Nov 27, 2013, at 11:07 AM, Tom Evans <tevans...@googlemail.com> wrote:
>
>> On Wed, Nov 27, 2013 at 4:55 PM, Ajtim <lum...@gmail.com> wrote:
>> OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013
>> r...@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.)
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
