From owner-freebsd-ports@FreeBSD.ORG Sun Nov 11 23:00:11 2007 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 300ED16A419 for ; Sun, 11 Nov 2007 23:00:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with SMTP id AC57313C480 for ; Sun, 11 Nov 2007 23:00:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 7579 invoked by uid 399); 11 Nov 2007 22:59:53 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 11 Nov 2007 22:59:53 -0000 X-Originating-IP: 127.0.0.1 Date: Sun, 11 Nov 2007 14:59:50 -0800 (PST) From: Doug Barton To: Stefan Sperling In-Reply-To: <20071111155343.GC1567@ted.stsp.lan> Message-ID: References: <20071111155343.GC1567@ted.stsp.lan> User-Agent: Alpine 0.99999 (BSF 796 2007-11-08) X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ports@freebsd.org Subject: Re: [PATCH] portmaster with SU_CMD X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 23:00:11 -0000 This is very interesting stuff, but I don't see how it would be useful to a very wide audience. My feeling is that the vast majority of our users build and/or install ports as root, and I don't see any good reason for that not to be the default practice. I'll review your patch more thoroughly when time allows (since we are in a freeze I can't add new features right now anyway) but I'm not inclined to add this unless there is a fairly substantial clamor for it. In fact I think I've passed a tipping point for portmaster where the complexity of the code, and the number of options (and thus, optional code paths) make adding new stuff very hard to do without introducing more bugs, and because there are so many different combinations of options it's hard to regression test improvements to existing features, never mind new ones. I'm not saying I'll never add a new feature, just that there needs to be a really good reason to do so. Doug -- This .signature sanitized for your protection