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

On Sat, Jul 31, 2004 at 11:12:20AM +0200, Oliver Eikemeier wrote:
> Mike Makonnen wrote:
> 
> >
> >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?

They will be confused because base system and ports rc.d scripts will
not behave the same. If a script in /etc/rc.d has a .sh extension in
/etc/rc.d it gets sourced in the same shell. If they put the script in
/usr/local/etc/rc.d it doesn't.

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

Except if it has a .sh extension.

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

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

.sh is what we have and that's what we should go with. Changing it to
something else would be a gratuitous change and digression from NetBSD
for the sake of compatibility with a non-STABLE branch.

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

You have no way of knowing what users want to do or what their circumstances
are. This would be be an instance of enforcing policy instead of
providing mechanisms for users to do what they want.

> 
> >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'?

It means you should not preclude users putting local rc.d scripts with
.sh extenstions in /usr/local/etc/rc.d. By barring it you are enforcing
a policy (your idea of what they should do). Whereas if rc.d scripts
in /usr/local/etc/rc.d behaved just like they do in /etc/rc.d, then
users can put their scripts wherever they think is appropriate for
their circumstances.

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

The people that will be affected by this are the people that run -CURRENT
or a prior 5.x release. We don't have to (and we shouldn't) provide
backwards compatibility for -CURRENT user. For those running a prior
5.x release we can provide patches to their rc.d/localpkg.

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

This feature MUST be put behind a knob. It
might have been okay if we had discussed this earlier in the 5-CURRENT
lifecycle, but not just before 5-STABLE. We need more time to evaluate
the impact of ordering ports rc.d scripts with the base system scripts.
Two weeks is not enough time.

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

How does what I committed break old-style scripts? It only breaks improperly
written rc.d scripts. (BTW I don't blame the maintainers for writing them
improperly-- they were relying on a buggy version of rc.d/localpkg)

The crux of my problem with your patch is this:

   You are proposing changing the behavior of rc.d for the sake of backwards
   compatibility with -CURRENT. Am I the only one who thinks this is crazy?


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 !