From owner-freebsd-ports@FreeBSD.ORG Mon Feb 27 22:52:32 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B4AAF106566C for ; Mon, 27 Feb 2012 22:52:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7E0C114F70A; Mon, 27 Feb 2012 22:52:30 +0000 (UTC) Message-ID: <4F4C092F.8080804@FreeBSD.org> Date: Mon, 27 Feb 2012 14:52:31 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Olivier Smedts References: <4F4BA7CE.20107@FreeBSD.org> <4F4BCF87.6070209@FreeBSD.org> <4F4BE02D.4020907@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: portupgrade -> portmaster Rosetta Stone? 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: Mon, 27 Feb 2012 22:52:32 -0000 On 2/27/2012 12:04 PM, Olivier Smedts wrote: > 2012/2/27 Doug Barton : >> On 2/27/2012 11:53 AM, Olivier Smedts wrote: >>> What about a command line flag to ignore errors during backup package >>> creation? >> >> What about ... no. :) > > Don't get me wrong, portmaster is a great tool, reliable, and I'm > using it nearly daily. > > But why not, if there's a reason ? "potential foot shooting" ? It's a general philosophy thing that is common to mergemaster and portmaster. I feel *incredibly* strongly that it's important for key system management tools to *not* make unsafe assumptions. I (and by extension the tools that I write) have no way to know what changes are mission-critical to a given user. Therefore, I have *no business* merrily blowing stuff away that the user may have been depending on. In the particular case of creating backup packages, with or without the -b option, the default assumption is that those packages are being *relied* on by the user to roll back an update in case of catastrophe. For users that don't care about what happens with the backup packages there is already a command line option to disable creation of them. My assumption is that if the user is not using the option to disable them altogether that the backup packages must have value. (Also, a meta-issue, if the ports developers are doing their jobs then backup package creation failure should be an incredibly rare occurrence.) OTOH, I got many requests from users to add a knob to bypass the warning about failed package creation. Personally, I don't like this knob, and would never use it. But in order to please the user base I added the feature, but included it as an "expert" option that requires configuration in an rc file. Frequently the next response to this line of reasoning is to insist that we're all grownups, and foot-shooting options should not be disallowed by policy. Well, fine. :) Go enable that option and blow off all the toes you want. My point is that the kinds of people who want a knob like that (expert users, frequent updaters, etc., and, not to hurt your feelings, but you're a very small percentage of the userbase) are precisely the same target audience that ought to be able to read the man page and configure expert options. hth, Doug (bet you wondered how I was gonna work that in, didncha) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/