Date: Tue, 24 Feb 2004 10:46:24 +0100 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-ports@freebsd.org Subject: Re: OPTIONS, LATEST_LINK, and RCng Message-ID: <403B1D70.1010100@fillmore-labs.com> In-Reply-To: <403AF015.1090307@mac.com> References: <20040223212225.1766.qmail@laurel.tmseck.homedns.org> <403A8643.1070500@mac.com> <403A919E.5010509@fillmore-labs.com> <403AF015.1090307@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chuck Swiger wrote:
>>> What's more of a concern to me is that variables like USE_RC_SUBR are
>>> used by the ports infrastructure without being documented in the
>>> Porter's Handbook, which perhaps might have avoided this particular
>>> debate.
>>
>> That is absolutely unfortunate, you are right. I was looking into parsing
>> what is in bsd.port.mk, to get at least some of the documentation there
>> into the porters handbook.
>
> Right-- while I don't have a problem with bsd.port.mk serving as the
> canonical documentation (assuming it is?), a lack of syncronization with
> the Porter's Handbook *will* confuse and frustrate people.
I guess a script that extracts the comments at the beginning of bsd.port.mk
and formats them as docbook is better than nothing. We should be able to do
this with nearly no changes to bsd.port.mk. I'll have a try if I have the
time, but if anyone else feels apt for the job, be welcome.
>>> I also have concerns about rcNG breaking things because ports which
>>> started up fine before now require an entry in /etc/rc.conf or else
>>> they silently fail, but that problem I had a patch for, if it hasn't
>>> gotten lost in the shuffle...
>>
>> This is another big issue we were discussing today. Do you still have
>> the
>> patch? I don't know if a message at startup is prominent enough...
>
> Found it, from Message-id: <2E8DD385-55B9-11D8-882E-003065ABFD92@mac.com>:
>
> --- rc.subr~ Fri Sep 26 11:52:23 2003
> +++ rc.subr Mon Feb 2 14:41:39 2004
> @@ -516,6 +516,8 @@
> #
> if [ -n "${rcvar}" -a "$rc_arg" != "rcvar" ]; then
> if ! checkyesno ${rcvar}; then
> + echo "Unable to ${rc_arg} ${name}: ${rcvar} not
> set."
> + echo "(Check /etc/rc.conf or try
> 'force${rc_arg}'...)"
> return 0
> fi
> fi
Yes, I wanted to incorporate something like that in PR 56736. Not sure if it
is enough, though. It *is* surprising if a port suddenly requires entries in
rc.conf, even though I know of no better way to do it.
> This addresses the concern of a startup script not doing anything and
> not displaying any indication to the user that the command did not run.
> It suggests to the user what they should change, and where, and also
> tells them how to use something like "forcestart" or "forcestop" if they
> still want to invoke the script manually.
>
> 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?
-Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?403B1D70.1010100>