RFC: Alternate patch to have true new-style rc.d scripts in ports

[Mike Makonnen]

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. 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. 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). 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. 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. To do otherwise
would be too confusing. IMO your patch contravenes the general policy of
"mechanisms, not policy."

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. 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.

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)
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.
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.

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.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon !