Date: 23 Feb 2004 21:22:25 -0000 From: tmseck-lists@netcologne.de (Thomas-Martin Seck) To: freebsd-ports@freebsd.org Subject: Re: OPTIONS, LATEST_LINK, and RCng Message-ID: <20040223212225.1766.qmail@laurel.tmseck.homedns.org> In-Reply-To: <403A594E.4010100@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Oliver Eikemeier <eikemeier@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040223212225.1766.qmail>