Date: Tue, 26 Nov 1996 16:34:25 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: peter@taronga.com, bmk@fta.com, jgreco@brasil.moneng.mei.com, brantk@atlas.com, hackers@FreeBSD.ORG Subject: Re: Replacing sendmail Message-ID: <199611262234.QAA17750@brasil.moneng.mei.com> In-Reply-To: <13469.849034313@time.cdrom.com> from "Jordan K. Hubbard" at Nov 26, 96 10:51:53 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Not in this particular set of examples, no, but understand that
> services have many more options *other* than security which you'd also
> eventually want to fold into the same mechanism. To contrive more examples:
>
> mail_control -fast_queue_depth 10
> mail_control -bounce_warnings no
> mail_control -add-virtual "fred sfred@scurvy.com"
>
> lp_control -polled-mode
> lp_control -set-type HP500C
>
> All of which might be reasonable things to want if you were intending
> to write a more robust front-end for a variety of service options.
>
> Think "big picture", guys. :-)
That's a nice big picture, I agree, but I am not talking about
configuration of packages. That might very WELL be addressed through
a mechanism like what you are describing!
I am more interested in the MANAGEMENT of packages, i.e., is a particular
package available and/or enabled? That is a higher level ("bigger
picture" ;-) ) question than configuration particulars.
CONFIGURATION of packages is a problem as well. I am not sure that it
is wise to try to solve both problems with the same tool, but am certainly
willing to discuss it if you believe that it is (I will tell you now: I have
a preconceived notion that it is not a good idea).
... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611262234.QAA17750>