OPTIONS, LATEST_LINK, and RCng

[Thomas-Martin Seck]

* Scot W. Hetzel (hetzelsw at westbend.net):

> From: "Thomas-Martin Seck" <tmseck-lists at netcologne.de>

> While, it will work, it causes the port-maintainer double duty, as they have
> to maintain both the rcNG and the rcOLD portions of the script.  Just fully

I am the squid maintainer and I can assure you that there is no
duplication of work in there. The rcOLD part was rewritten to reuse the
variables that already had to be declared in order to actually use rcNG.
And frankly: once these scripts work, they are hardly ever touched
again.

> convert your script to rcNG as we want to eventually get rid of all the
> rcOLD scripts.  The rc_subr port is just a transition aid to allow these
> scripts to run on pre-rcNG systems.

Well, the script we are talking about is an rcNG script. It is an rcOLD
script too. It adapts to its environment without needing to pull in
rc_subr. The only problem is that its overly friendly to rcNG and tries
to pull in $PREFIX/rc.subr. That part will be removed. Otherwise I am
not too happy to be advocated into rcNG, since I respect it and just
ask for my decision to maintain compatibility between rcNG and rcOLD to
be respected, too.

> Before I submited the patches to bsd.port.mk for USE_RC_SUBR and provided
> the port for rc_subr.  I was looking at the NetBSD tree to see how they had
> transitioned from their old rc system to their new rc system (rcNG).  They
> used a mix of both rcOLD and rcNG.  And I started converting my scripts to
> follow the way NetBSD did it.   Then I looked at it again, and realized that
> these scripts would need to be in the tree forever.  Also when anyone brings
> a new port in and it needs an rc.d scripts, it would also require them to
> use a mix of rcOLD and rcNG, so that they would stay compatible with
> previous releases.  I determined that this mix of rcOLD and rcNG scripts
> wasn't acceptable and came up with our current way of creating pure rcNG
> scripts.

Well, just because you do not like that it does not make it bad per se.

I have no problem with providing compatibility for some amount of time.
When the ports collection will only support systems that are rcNG - and
I bet this time will come sooner or later - there is still time to
remove compatibility hooks. Why put yourself under pressure just for
aesthetic reasons? To be honest: when this discussion got fully engaged
I was tempted to remove all rcNG stuff from squid.sh just to annoy the
rcNG evangelists.

My intention is to use rcNG where appropriate and fall back to rcOLD. I
agree that using rcNG on systems with rc_subr installed without
explicitly saying so by registering a dependency on rc_subr can be a
POLA violation (though not as gross as some people liked to make it,
since the effect is documented in squid.sh and I expect the admin to
read the start scripts) and I will remove that part as I already said.

> No, pulling in sysutils/rc_subr solves more problems than you realize.
> 
>        1. It provides a common set of functions available to all rc.d
> scripts (checkyesno, load_rc_config, run_rc_command, ...)
>        2. It provides a common set of commands available to all rc.d scripts
> (start/stop/restart/[status/poll]/[extra commands])

Yes, rcNG is nice since it unifies a lot of stuff that currently exists
in various home-brewn variations in the tree. Once again, I like rcNG,
just for the archives. I do not like the USE_RC_SUBR know. Why? It still
provides  no incentive for a port maintainer to actually convert his/her
script when he/she does not bother about rcNG, since on pre-5 it will
still work. There is now way to "get rid of" rcOLD scripts this way as
long as there are still pre-5 systems out there. But instead of making
sure that all port startup scripts use rcNG when it will be the default,
talking maintainers into "USE_RC_SUBR, it will make the world a better
place" has created a situation where scripts have prematurely been
converted to rcNG without offering any compatibility to the rc mechanism
in -STABLE's base system thus needing to pull in yet another dependency.
As said already, I tend to avoid pulling in dependencies when I can do
without. Even more so when their only incentive seems to be evangelism,
since evangelism tends to annoy me really quickly.

> The placing of the scripts in their proper order is the job of /sbin/rcorder
> (only on 5.x+).  Rcorder functions by reading the comments in a rc.d script
> for specific keywords in order for it to determine in which order to place
> the script.  Currently, rcorder is not being used on -Current to start the
> ports startup scripts because only a small portion of them have been
> converted.

I really don't like the term "converted". rcNG awareness (upwards
compatibility so to say) really is sufficient IMO and I am quite happy
with squid being able to play in both leagues without forcing anything
upon the user. Whether you like it or not, it works.

> NOTE: rcorder of the ports startup scripts is planed for -Current, but they
> are waiting for the ports scripts to be converted.

I'd be happy if the existing scripts were made to be rcNG compatible
instead of blindly rewriting them to be rcNG only and thus needlessly
forcing yourself to USE_RC_SUBR on pre-5 because otherwise the script
would just be broken.