> I agree with this.  But it would be 'make replace' that would have the
> override, because that's where the bookkeeping is about what's dirty.
> Or perhaps two kinds of dirty flags, unsafe_depends and safe_depends,
> the latter for when an upgrade happened but the rules say it was ok.

I like that option. If only one flag is set and you end up with problems, and 
there is no way to override in the upgrade tool, it means it is non-trivial 
to fix. But if both flags are set (or if the tool allows one to override), 
one can easily revert back to excessive recompilation when you do run into 
trouble.

If the only override available is to change the behavior of unsafe_depends, I 
would personally tend to just disable the smart behavior alltogether and take 
the recompilation hit. But then one looses the advantage of having the flag 
to begin with.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org