Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg)

Mike Makonnen wrote:

> On Wed, Jul 28, 2004 at 05:16:18PM +0200, Oliver Eikemeier wrote:
>> Appended is an alternate patch to have true new-style rc.d scripts in
>> ports. Scripts in ${local_startup} are processed as follows:
>>
>> - scripts ending in .sh are treated as old-style scripts, which means
>> they need to have it's executable bit set to be considered by localpkg
>> as before. Whether they partially use rc.subr features or not isn't
>> relevant. They are executed in lexicographical order like specified in
>> rc(8).
>>
>> - scripts without any extension participate in a system wide 
>> rcorder(8).
>> To enable diskless booting and remote mounting they are not executed
>> before a configurable barrier script ${rclocal_barrier} is executed,
>> which is PORTS is this patch. Whether or not the script is has it's
>> executable bit set is not examined.
>
> I appreciate the effort you are putting into this. However, these hacks
> will only end up confusing users to no-end.

I don't think so. The patch is completely backwards compatible, which 
means everything will run as it did before. Why should anyone be 
confused by that?

> Don't forget that it is
> not only ports scripts that go in /usr/local/etc/rc.d. Lots of users
> also choose to put their local scripts there instead of /etc/rc.d. This
> means that their scripts will behave differently depending on whether
> they put them in /etc/rc.d or /usr/local/etc/rc.d.

As stated above: everything users did before will continue to work. 
Besides, the patch finally unifies /etc/rc.d and /usr/local/etc/rc.d in 
the most important aspect: participating in rcorder(8). A new-style 
script will do the same, no matter whether put in /etc/rc.d or 
/usr/local/etc/rc.d. 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.

> Also, it's not
> a good idea to bar the possibility that a future port might need
> to be sourced in it's parent shell (i.e in /etc/rc).

I consider this to be dangerous. When we ever need such a functionality, 
we should choose a less prominent extension that `.sh' for that, or scan 
for a special keyword.

> Also, a sysadmin
> might have a local script in /usr/local/etc/rc.d that may for example,
> load a different rc.conf depending on circumstances.

{He,She} might, although I consider such a functionality to be exotic 
and fragile. Anyway, /etc/rc.d could be used for that purpose.

> Additionally,
> if ports rc.d scripts are going to participate in the boot rcorder(8)ing
> then they need to behave like the base system rc.d script.

Jup, that is the purpose of this patch.

> To do otherwise
> would be too confusing. IMO your patch contravenes the general policy of
> "mechanisms, not policy."

Ehm, what does that mean? A policy that states `no policies'?

> As far as including ports in the boot ording process:
>
> I think the last patch in your PR is preferable to this version. This
> version essentially makes it very likely that changing rclocal_barrier
> will break the boot. This is because by a changing rclocal_barrier the
> user is likely to break the REQUIRE and BEFORE relationships between 
> ports
> and base system rc.d scripts so that it's possible that a ports rc.d
> script is sourced after a script it specified in its
> BEFORE line.

The new patch is slightly improved, but we could substitute 
rclocal_barrier by PORTS everywhere. It was just meant as an additional 
safety measure, but when we don't need it: s/\${rclocal_barrier}/PORTS/g.
Filtering out the .sh scripts solves the problems mentioned in the PR and 
avoids the recent breakage.

> Additionaly, if we have rc.d/PORTS this knob is simply
> redundant. I think the best solution is the one in your PR. Have
> all ports rc.d scripts REQUIRE the PORTS service and if the user wants
> to change the position in which ports scripts are sourced, then he
> should simply edit rc.d/PORTS and place it where he wants.

Ok, I have absolutely no problem with s/\${rclocal_barrier}/PORTS/g.

> Here is the solution I would support:
> 1. Ports and base system rc.d scripts behave the same:
>    .sh scripts are sourced in the current shell, others in a subshell.
>    (Basically, what I committed)

ports .sh script shouldn't be sourced in the current shell, since these 
are old-style startup scripts that won't work with the changed semantics 
(as we had to observe recently). When you insist on being able to source 
ports scripts, let's change the extension to something less dangerous, 
like `.rc', `.src' or whatever you like. We could even do this with the 
base scripts, for the sake of uniformity.

> 2. Sourcing of ports rc.d scripts with the base sytem scripts to be
>    put behind a knob. If the knob is enabled rc.d/localpkg does not
>    run rc.d scripts in the local_startup directories. If it is turned
>    off, then rc.d/localpkg does ports rc.d scripts in addition to the
>    legacy scripts.

I see no reason why localpkg should do rc.d scripts. It was always meant 
to execute old-style scripts, and this behavior shouldn't be changed. 
Why do you want to introduce a semantic split here, that you seem to try 
to avoid above?

> 3. An /etc/rc.d/PORTS scripts that all ports rc.d scripts must REQUIRE.
>    My inclination is to put it right after rc.d/mountcritremote. This
>    probably gives the best  useful:safe ratio.

Fine with me.

> It was mentioned in another thread that this would break compatibility
> with people running a prior 5.x release (-current does not qualify for
> backwards compatibility in my book). Since we are talking about four
> releases (5.0, 5.1, 5.2, 5.2.1) it should be easy enough to provide
> patches for their rc.d/localpkg scripts. The patch could be a "required
> upgrade" (we still have those I believe) for those people.

It's easy not to break backwards compatibility, so why should we do 
this, especially shortly before going -STABLE? I can't see what the real 
benefits of this approach are. Old style scripts rely on documented 
behavior in rc(8), so there is no reason to break them.

-Oliver