OPTIONS, LATEST_LINK, and RCng

[Thomas-Martin Seck]

* Oliver Eikemeier <eikemeier at fillmore-labs.com> [gmane.os.freebsd.devel.ports]:

> Don't. This is no upgrade path, either use rcNG or not, but don't change the
> behaviour of your port based on other ports configuration. If you don't like
> rcNG, stick with the old script.

Well, you can check in your start script whether /etc/rc.subr is present
and act accordingly.  I will change squid to behave this way so it can
use rcNG on a recent 5.x and "rc classic" on pre-5-system. I think this
is acceptable, isn't it?

> Take *any* other port with an rc.subr script as an reference. If you want to
> use rc.subr then depend on it, it's <30k, and set USE_RC_SUBR="YES". We are
> managing 10k+ ports, and it helps if everybody tries to play by the rules.

Do you really think that discussing the "rules" via a (self assigned) PR
from committer to maintainer helps improving their acceptance? I doubt
it. Never do that again, please. On the other hand, I agree that my idea
of trying to make use of sysutils/rc_subr without explicit dependency is
not really DAU-compatible. That's what you get from trying to be nice to
rcNG, I guess.

> Besides, currently you get alphabetical order no matter what you do.

Great. So rcNG is currently not even completely working for ports?
Methinks that pulling in sysutils/rc_subr creates more problems than it
solves. (Don't get me wrong: I really like rcNG, I just don't like the
idea of a port being able to change the system startup -- and that is
what rc_subr does).