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

[Oliver Eikemeier]

Mike Makonnen wrote:

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

Lets be realistic: Nearly nobody wants his scripts to be sourced in the 
startup shell, especially not in /usr/local/etc/rc.d. People who really 
want to do this are experts that exactly know what they are doing, and 
are not easily confused.

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

Which prevents a lot of breakage.

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

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

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.

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

When you have no way of knowing what users want to do, how can you 
provide mechanisms for them to do so?

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

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

(b) While doing this, I want to keep documented behaviour, so users can 
keep what worked for them before.

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

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.

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

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. 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. And we have time for 
an adequate migration phase, which will help us detect problems. What 
should be the issues of ordering ports rc.d scripts with the base system 
scripts, especially when we require that nearly every of them has a 
`REQUIRE: LOGIN' line? I except very few have the need for something 
else, but the base will greatly benefit from them.

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

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

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

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.

-Oliver