From owner-freebsd-current@FreeBSD.ORG Wed Jul 29 17:06:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CDB21065673 for ; Wed, 29 Jul 2009 17:06:13 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from tafi.alm.flutnet.org (tafi.dsl.alm.flutnet.org [145.99.245.99]) by mx1.freebsd.org (Postfix) with ESMTP id F05568FC0A for ; Wed, 29 Jul 2009 17:06:12 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from localhost (localhost [127.0.0.1]) by tafi.alm.flutnet.org (Postfix) with ESMTP id 6AAFC78C25; Wed, 29 Jul 2009 19:06:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at alm.flutnet.org Received: from tafi.alm.flutnet.org ([127.0.0.1]) by localhost (tafi.alm.flutnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0kCkGRm0675; Wed, 29 Jul 2009 19:06:01 +0200 (CEST) Received: by tafi.alm.flutnet.org (Postfix, from userid 1000) id 6338678C23; Wed, 29 Jul 2009 19:06:01 +0200 (CEST) Date: Wed, 29 Jul 2009 19:06:01 +0200 From: Alson van der Meulen To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20090729170601.GA2841@tafi.alm.flutnet.org> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <200907232335.54973.mel.flynn+fbsd.current@mailing.thruhere.net> <4A6FF5FA.5010904@FreeBSD.org> <200907282342.25038.mel.flynn+fbsd.current@mailing.thruhere.net> <4A707534.8000808@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A707534.8000808@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:06:13 -0000 * Doug Barton [2009-07-29 18:13]: > Mel Flynn wrote: > > Gotcha. Is there a reason the flags are removed if the options are not "-r or > > -f"? > > Yes, so we don't have stale flags sitting around forever to confuse > future runs. I have been bitten by this in the past. A run of portmaster -r some-lib-that-half-of-my-ports-depend-on aborted because of a shared library error in a dependency which was not recompiled before the dependent port. I recompiled the dependency with a manual portmaster $portname, after this portmaster -r had to start all over. I didn't expect portmaster to clear the PM_DONE flags during non-resumable operations like rebuilding a single port (and the manpage contains very little information about -R). My workaround is to use portupgrade for these manual fixes. The case where not removing the flags without -[rf] would hurt is running portmaster -r something, portmaster failing, resolving this without portmaster -[rf], updating your ports, and run portmaster -R. It seems fair to consider this behavior undefined. Plus the ports can be modified in many ways without portmaster, so it would make more sense to try to detect stale PM_DONE flags than removing them at arbitrary times (eg. compare the timestamp of the flag to that of the port). Alson