Date: Sat, 31 Jul 2004 17:42:05 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Mike Makonnen <mtm@identd.net> Cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) Message-ID: <2CA903DA-E308-11D8-9C56-00039312D914@fillmore-labs.com> In-Reply-To: <20040731145616.GA14576@rogue.acs-et.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Makonnen wrote:
> On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote:
>> Mike Makonnen wrote:
>> [...]
>>>> Legacy script were never executed when put in
>>>> /etc/rc.d, and won't after this patch. I can't really follow your
>>>> argument here.
>>>
>>> I'm not talking about legacy scripts. I mean local rc.d scripts.
>>
>> Local rc.d scripts will continue to be executed as before.
>
> except if they have a .sh extension.
No, they will be executed like before.
>> I'm not exactly concerned with NetBSD compatibility here, especially
>> considering the facts that (a) rc.subr has already set_rcvar with `case
>> ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in
>> NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with
>> an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the
>> only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist
>> in FreeBSD. Compatibility with NetBSD seems to be a myth, especially
>> since they never bothered to merge the changes back from FreeBSD.
>
> I don't mean source code compatibility. I don't really care *too much*
> about that either. What I am concerned with is compatibility
> behaviour-wise.
AFAIK NetBSD has added the ability to let pkgsrc scripts participate in
rcorder(8) two years ago, similar to my patch integrated into
rc/rc.shutdown. They seem to have no problems with that so far. When you
only care about compatibility behaviour-wise, what's the big deal of
changing the extension for sourcing? `.sh' bears already a documented
meaning on FreeBSD, denotating an old-style rc script. Let's move to
`.rc' for a sourced rc.d script.
> [...]
>> (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like
>> they do in /etc/rc.d, namely participate in rcorder(8). This was the
>> most common reason to move scripts from /usr/local/etc/rc.d to
>> /etc/rc.d.
>
> If ports rc.d scripts with .sh extensions aren't sourced in the same
> shell,
> then they don't behave "exactly like they do in /etc/rc.d".
> Participating
> in the boot ordering is not the stick by which the "rc.d'ness" (for lack
> of a better word) of a script is measured.
It's one of the main features, besides having a standard way to
enable/disable services.
>> (b) While doing this, I want to keep documented behaviour, so users can
>> keep what worked for them before.
>
> Correction-- what worked for them in most of 5-CURRENT up to now.
and on 4-STABLE. What is the difference of your statement and mine?
>> We shouldn't break backwards compatibility for no good reason.
>> Compatibility with NetBSD in aspects we never have been compatible is
>> not a good reason to introduce an incompatiblity with -CURRENT.
>
> We *have* been compatible with respect to behaviour of an rc.d script.
> While we have digressed somewhat by *adding* features, the base
> behaviour
> is the same.
You are always compatible to *something*, of course. I'm talking about
*backwards* compatibility.
> Additionaly, compatibility with -CURRENT is not a valid
> excuse for introducing hacks or allowing buggy behaviour to continue.
No hacks here, and no buggy behaviour observed.
>> [...]
>> I see absolutely no problems with having this feature now. You wanted
>> similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and
>> this is what this patch provides.
>
> *sigh* No, it doesn't. It hacks rc.d to treat /usr/local/etc/rc.d
> scripts
> with a .sh extension as old style scripts. That is not the same thing.
Ok, lets move to `.rc' to make some progress in this issue then.
>> It is completely backwards compatible,
>> so we don't have to fear breakage. Every new port that starts to
>> participate in rcorder(8) could be tested individually by the
>> maintainer
>> before submitting, so this should be pretty save.
>
> NO, because it's impossible for the maintainer to test it with even a
> fraction of the possible combinations. Remember that the script has to
> play nice with the scripts as they are currently in /etc/rc.d, with any
> future changes we might have to make to the ordering, with any
> new scripts we might add in the future (or we might have to remove
> a script the script depends on), with current ports rc.d scripts,
> with future ports rc.d scripts, and with any local rc.d scripts
> written by a user. By defenition, it is impossible for a maintainer
> to be absolutely certain that his script will not break something.
NetBSD seems to be able to cope with this situation for two year now. Of
course a wrongly written startup script could break things, but this was
already possible before. A script could for example hang, I've
experienced this serveral times myself.
> [...]
>> Ah, no: They where relying on documented behaviour in rc(8). localpkg
>> is
>> not buggy, and should not be changed. The scripts are not buggy either,
>> they are simply old-style scripts that source rc.subr and use some of
>> its features. They have never been tested as rc.d scripts, but it
>> should
>> be easy to convert them to become that, since they are pretty similar.
>> Nevertheless one should not be confused of their character because of
>> their similarity to rc.d scripts: they are not, and should not be
>> treated so. Read rc(8) on how they should be handled. What we are
>> trying
>> to do here is to introduce a *new* functionality, which requires new
>> scripts (although they conversion should be easy in most cases).
>>
>
> Oh please, let's not get into semantic arguments here. If they
> source /etc/rc.subr and implement the functionality that typically
> defines rc.d scripts, then thay are rc.d scripts (or atleast
> they are trying to be).
They use a feature of rc.subr: a standard way to enable and disable
services. That doesn't make them to fully compliant rc.subr scripts (and
most of them never tried to be), and they should not be treated as such.
> And since you brought up rc(8), these rc.d scripts you want to treat
> as old style scripts violate one of the rules of old-style scripts:
>
> o The output from each script is traditionally a space
> character, fol-
> lowed by the name of the software package being started or
> shut down,
> without a trailing newline character (see the EXAMPLES
> section).
many old-style script violate this rule. I don't consider this to be a
big problem.
> rc(8) also gives a clear example of what an old-style ports script
> should
> look like:
>
> The following is a simple, hypothetical example of an old-style
> /usr/local/etc/rc.d/ script, which would start a daemon at boot
> time, and
> kill it at shutdown time.
> [...]
... which is an example and no requirement.
>> The only proposal I made in changing the behavior of rc.d is changing
>> the extension to something more well thought out, like `.rc'. Said
>> that,
>> I can live with keeping `.sh' as the extension for sourcing rc.d
>> scripts, although it will do us no good. Anyway, I'm not a big fan of
>> changing documented behavior, be it -CURRENT or not. I think this is a
>> pretty reasonable attitude, but YMMV.
>
> Ok, can you do the following then:
>
> 1. When you (portmgr) are ready put back the rc.d/localpkg changes
> 2. Put the ordering of ports scripts with base system
> scripts behind an rc.conf(5) knob, and modify your patch so both
> /etc/rc and /etc/rc.d/localpkg do the right thing depending on
> whether
> it's on or off.
I suggest changing the extension for sourcing scripts to `.rc' and
ignore `.sh' scripts in rc/rc.shutdown. The unmodified localpkg
should handle these.
-Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CA903DA-E308-11D8-9C56-00039312D914>