From owner-freebsd-hackers Mon Nov 25 22:05:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA12560 for hackers-outgoing; Mon, 25 Nov 1996 22:05:34 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA12553 for ; Mon, 25 Nov 1996 22:05:31 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.2/8.6.9) with ESMTP id WAA10629; Mon, 25 Nov 1996 22:03:52 -0800 (PST) To: bmk@fta.com cc: jgreco@brasil.moneng.mei.com, brantk@atlas.com, peter@taronga.com, hackers@freebsd.org Subject: Re: Replacing sendmail In-reply-to: Your message of "Mon, 25 Nov 1996 21:25:17 PST." <199611260525.VAA01070@everest.dtr.com> Date: Mon, 25 Nov 1996 22:03:52 -0800 Message-ID: <10627.848988232@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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