Date: Wed, 27 Nov 2013 14:35:51 -0600 From: Cb <milios@ccsys.com> To: Tom Evans <tevans.uk@googlemail.com> Cc: freebsd-ports <ports@freebsd.org>, Ajtim <lumiwa@gmail.com> Subject: Re: warning Message-ID: <68956DF4-7854-4D8A-9E0B-1FC7F40FDE3B@ccsys.com> In-Reply-To: <CAFHbX1JmQvPWNJ5BmEL9SCD6ny6tKu8%2BhH9ydOeC3QDqTxWYTQ@mail.gmail.com> References: <3949129.efd2ojFSgk@lumiwa.farms.net> <CAFHbX1JmQvPWNJ5BmEL9SCD6ny6tKu8%2BhH9ydOeC3QDqTxWYTQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Nov 27, 2013, at 11:07 AM, Tom Evans <tevans.uk@googlemail.com> wrote:
>=20
>> On Wed, Nov 27, 2013 at 4:55 PM, Ajtim <lumiwa@gmail.com> wrote:
>> OS: FreeBSD 10.0-BETA3 #0 r257580: Sun Nov 3 19:43:01 UTC 2013 root@=
snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
>>=20
>> When I boot a computer I got one warning:
>>=20
>> /etc/rc: WARNING: $tcsd_enable is not set properly
>=20
>=20
> This is part of a port, security/trousers. Reinstall it?
>=20
> Cheers
>=20
> Tom
There are more than a few ports in the tree right now that are causing warni=
ngs just like that one to be emitted. (I didn't check security/trousers to s=
ee if what I describe below is actually it's crime. It is likely that this i=
s 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 variab=
le (which should almost invariably be a "NO").
Somewhere in the rc.d file for foo, before calling load_rc_config, is suppos=
ed to be a line similar to this:
: ${foo_enable:=3D"NO"}
At least, that's how I've been doing it and how I understood things. Please c=
orrect 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 th=
ey 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 noti=
ce 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 sw=
itch 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 pa=
ckage installed, it might indeed be a good idea to default to its complete o=
r partial activation during startup _without_ the end-user explicitly enabli=
ng 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 exp=
and my view. I can think of no such instance, but I understand the theory be=
hind 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 effec=
t, as the lack of a variable obviously implies checkyesno will exit 1 (i.e. r=
eturn "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 i=
nstall a thousand packages and have nothing else magical happen until one im=
plicitly 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 anyo=
ne's thoughts if they default a port of theirs to do anything at all during s=
tartup without an explicit enable, even though my imagination currently offe=
rs me no such picture.)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68956DF4-7854-4D8A-9E0B-1FC7F40FDE3B>