From owner-freebsd-stable@FreeBSD.ORG Wed Aug 26 22:28:28 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E771065690; Wed, 26 Aug 2009 22:28:28 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 600C28FC2C; Wed, 26 Aug 2009 22:28:27 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n7QMSFlE012138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Aug 2009 15:28:15 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7DA1F1CC09; Wed, 26 Aug 2009 15:28:15 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Wed, 26 Aug 2009 12:59:19 PDT." <4A959417.9000208@FreeBSD.org> Date: Wed, 26 Aug 2009 15:28:15 -0700 From: "Kevin Oberman" Message-Id: <20090826222815.7DA1F1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-26_13:2009-08-26, 2009-08-26, 2009-08-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0907200000 definitions=main-0908260176 Cc: freebsd-stable@freebsd.org, Nenhum_de_Nos Subject: Re: portmaster not ask for port deletion X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 22:28:28 -0000 > Date: Wed, 26 Aug 2009 12:59:19 -0700 > From: Doug Barton > Sender: owner-freebsd-stable@freebsd.org > > Skip Ford wrote: > > Doug Barton wrote: > >> Yes, unfortunately it's not omniscient. :) > > > > Well, to be honest, it wouldn't need to be. It would just need a flag > > to know when nobody is present from whom to request input, and then take > > the default action. > > That's never going to happen. The default choice is not going to be > the right one for some percentage of users. > > > But, if all input is requested during config, then > > that's pointless. > > Yes, that's the goal. > > >> Second, without knowing what command line you used I couldn't tell you > >> for sure what happened of course, but assuming you used some > >> combination of '-af' what you saw was expected behavior. There is a > >> conflict (I think a fairly obvious one) between the -f option and > >> +IGNOREME. Since different users would have different ideas of how to > >> resolve that conflict, portmaster takes the safe path and asks you. > > > > Well, it wasn't immediately obvious to me that someone would ever want to > > mark a port ignore and then want to upgrade it. So, it just seemed like a > > silly question to me (and still does to be honest, unless that's the > > behavior of portupgrade you're trying to match.) > > I honestly don't know what portupgrade does in that situation. There > are at least 2 classes of users that I am trying to "protect" in this > case: > 1. Users who believe that -f should override +IGNOREME > 2. Users who create an +IGNOREME file for some reason, then forget > it's there. portupgrade does the same thing except that you "hold" them instead of ignoring them. I believe that this is the correct way. I have ports (e.g. openoffice.org) that take a VERY long time to build or that are run in production out of a crontab (rancid). I don't want to inadvertently update these with the '-a' option. (Especially th latter case.) When I really, really want to do them, I use '-f'. I think of '-f' as "YES, I REALLY, REALLY, REALLY want to update this port now and I expect you to believe me". > One of the problems with writing a tool like portmaster is that a lot > of users have very strong ideas about how it should work, and very > clear reasons for why they think that their way of looking at it is > the right way. :) Unfortunately, there is usually an equal number of > users on the other side who feel just as strongly. Yep, You can never design a tool more complex than a rock that will please everyone. Wait, that rock is too (soft | small | large | rounded | sharp | etc) for me. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751