OPTIONS, LATEST_LINK, and RCng

Chuck Swiger cswiger at mac.com
Mon Feb 23 15:01:30 PST 2004


Thomas-Martin Seck wrote:
> * 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?

That sounds reasonable, at least if your script behaves the same regardless of 
whether rcNG is present or not.  It would be easier to simply make a start 
script which does the right thing independant of rcNG, but if you want to 
pursue the direction you've taken, your port should set USE_RC_SUBR under 5.x.

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

Oliver really is trying to help, Thomas, and his suggestions tend to 
well-founded.  Ideally, we'd all be a little more diplomatic and we'd all 
respond well to the notion that there are "rules", or "guidelines", or 
"suggested approaches" so that the ports system works well.

Catching missing dependencies and the proper use of the USE_ variables is 
important because if things are done wrong, other ports may break when you 
change/update your port.  Admittedly, these problems tend to happen more with 
libraries than an app like Squid (see the churn over gettext & libiconv).

What's more of a concern to me is that variables like USE_RC_SUBR are used by 
the ports infrastructure without being documented in the Porter's Handbook, 
which perhaps might have avoided this particular debate.

I also have concerns about rcNG breaking things because ports which started up 
fine before now require an entry in /etc/rc.conf or else they silently fail, 
but that problem I had a patch for, if it hasn't gotten lost in the shuffle...

-- 
-Chuck



More information about the freebsd-ports mailing list