From owner-freebsd-ports@FreeBSD.ORG Wed Nov 27 20:46:59 2013 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB66EB6A for ; Wed, 27 Nov 2013 20:46:58 +0000 (UTC) Received: from cargobay.net (cargobay.net [174.136.100.98]) by mx1.freebsd.org (Postfix) with ESMTP id 66431272B for ; Wed, 27 Nov 2013 20:45:50 +0000 (UTC) Received: from [192.168.1.80] (70-138-180-58.lightspeed.hstntx.sbcglobal.net [70.138.180.58]) by cargobay.net (Postfix) with ESMTPSA id E145A15BF; Wed, 27 Nov 2013 20:31:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: warning From: Cb X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Wed, 27 Nov 2013 14:35:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <68956DF4-7854-4D8A-9E0B-1FC7F40FDE3B@ccsys.com> References: <3949129.efd2ojFSgk@lumiwa.farms.net> To: Tom Evans Cc: freebsd-ports , Ajtim X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:46:59 -0000 > On Nov 27, 2013, at 11:07 AM, Tom Evans wrote: >=20 >> On Wed, Nov 27, 2013 at 4:55 PM, Ajtim 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.)=