Mark Kettenis [mark.kette...@xs4all.nl] wrote: > > Perhaps not as stupid as you think. > > OpenBSD provides a complete base OS. In principle you only need to > install packages for add-on software. And there should be no need for > such add-on software to be started before the base system is up and > running. You only run into "problems" when you try to replace things > from the base system with stuff from ports. I'd argue that in that > case you're no longer running OpenBSD, and therefore it is a good > thing you need to go through some hoops in order to do this. > > In the particular case of unbound, there is some consensus that we > should replace BIND in base with nsd and unbound. But it seems nobody > actually cares enough to do the work to make this happen.
If rc.d provides functionality, it should be usable in cases where you expect it to, or it should at least be documented why it is broken. If an alternative server for syslogd, ldattach, pflogd, named, nsd, ntpd, isakmpd, iked, sasyncd, or ldapd isn't suitable then why is it even in ports ? Some people have specific needs that most people don't? Some of these tools are generally known to be lower quality, yet stay in ports for the same reason. They're useful, but not encouraged. We don't want to make rc.d good enough to help these people because it's "another knob". So, the perception here is that rc.d is aimed at the "set it and forget it" folks who aren't qualified to use ports? Do you use rc.d? I use rc.d. And, probably like you, I used it because it was convenient. And, I am satisfied with it. So while I understand the arguments against fully implementing rc.d, I can't agree that I don't want the pkg_early_scripts convenience there for myself.
