Date: Mon, 25 Nov 1996 22:03:52 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: bmk@fta.com Cc: jgreco@brasil.moneng.mei.com, brantk@atlas.com, peter@taronga.com, hackers@freebsd.org Subject: Re: Replacing sendmail Message-ID: <10627.848988232@time.cdrom.com> In-Reply-To: Your message of "Mon, 25 Nov 1996 21:25:17 PST." <199611260525.VAA01070@everest.dtr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> MTA selection can be handled by doing 'pkg_control -disable sendmail; > pkg_control -enable qmail'. Of course, for novices, this operation > would be hidden behind the slick UI that hasn't been written yet. Ok, well, the real question I still have here is "what determines the intelligence behind the enable/disable action?" What I mean by this is that while it's relatively easy to quantify the enable/disable actions for sendmail/qmail, by calling your utility "pkg_control" you're intimating that this thing will work effectively for *all* packages which might be enabled or disabled. To use a totally contrived example, let's say I wanted to disable all forms of remote login access except for ssh (as many people do). I would expect to be able to say: pkg_control -enable ssh pkg_control -disable rlogin,telnet [yes, I know that rlogin and telnet aren't packages but ssh is, so already we're into a real grey area, just as with sendmail]. The actions behind making this happen are quite different than the sendmail/qmail selection actions, and this package-specific intelligence has to go *somewhere*, right? Or let's say I wanted to install apsfilter as my default printer filter. I might want to say: pkg_control -enable apsfilter Which would entail yet another entirely different set of operations. Short of making pkg_control a humongous beast from hell with inate knowledge of every possible package you might want to enable or disable, it seems like a generic package control program is something of a bitch to do, and by calling it "pkg_control" that's exactly what you're suggesting it does. That's why I suggest doing this more incrementally by service type. In my examples, there would actually be something like 3 different commands: mail_control -enable qmail -disable sendmail access_control -incoming -enable ssh -disable rlogin,telnet lp_control -enable apsfilter Each command would have a much easier time of it since it only has to know about a limited set of services. By keeping the argument names orthogonal (though I think that -enable and -disable are a bit stretched in some of these examples :-), it's also easier to write a front end which can feed them all. Just my 2 cents. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10627.848988232>