[ ... ]

One thing that surfaced frequently in a discussion of a similar system was hard vs. soft requirements.

Specifically, I can run sendmail without a syslogd running, so it is not a hard requirement, but I would prefer that it be there so that I can log things.

There is a similar non-requirement for bind to start sendmail, if you have it configured to not probe interfaces, which is a good idea for dial-on-demand configurations, but to provide service to a remote system, it needs bind around.

So along with "PROVIDE" and "REQUIRE", there's a need for "WANT"; it could be used as a tie-breaker for circular dependency lists, if such occur.

Similarly, there is a need for a "config", as well as a "start", "stop", "restart", and "Status". For well written software, this would end up being a NOOP, since it would not cache config data, but would instead obtain it each time (an example of bad caching is sendmail source host name caching, when an ISP supports DNSUPDAT based on RADIUS audit events: if the machine claims to be named something different than the ISP assigned DNS name such that forward and reverse mappings don't match, the ISP will reject attempts to relay email from valid customers).

Yeah, in a perfect world, everyone would have a static IP address, and sendmail would have a knob to make it do a gethostbyaddr() for each time that it wanted to say "HELO", etc., etc..

Oh... and the PROVIDE/REQUIRE/WANT lists really, really want to be "per service name" rather than per program name, so I could, for example, have a service that depends on "smtpserv", and not care if it was sendmail or qmail or whatever, only that there was a protocol aware program sitting on the SMTP port, waiting for a connection.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message