[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-stable
Subject:    Re: HEADS-UP: Shared Library Versions bumped...
From:       Alson van der Meulen <alson+ml () alm ! flutnet ! org>
Date:       2009-07-29 17:06:01
Message-ID: 20090729170601.GA2841 () tafi ! alm ! flutnet ! org
[Download RAW message or body]

* Doug Barton <dougb@FreeBSD.org> [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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]