Dislike the way port conflicts are handled now

[b. f.]

Argh!  Stop! I wish that people who felt the need to add to this
thread would read the prior posts beforehand, and consider their
comments before posting.  To answer two previous posts:

>> I believe that he is talking about changing _when_ the check for
>> conflicts is made; whereas DISABLE_CONFLICTS ignores the check,
>> regardless of when it is made.  A late check is preferable to using
>> DISABLE_CONFLICTS, because with that knob you can shoot yourself in
>> the foot by mistakenly installing one port on top of another.
>
>I think the point is you can make -DDISABLE_CONFLICTS using targets
>other than install

?! Obviously, you can use it for other targets.  That doesn't seem to
have been in doubt.  The point is rather that if one disables the
conflicts check and then accidentally uses the 'install' target or
another target requiring 'install', and there is a conflicting port
already installed, there are going to be problems.  Of course that
wouldn't be a good idea, but it can happen, and that is the point of
having a check.

------------------

>The idea of the change seems to be to protect people from wasting time
>downloading and building something which they can't install without resolving
>a conflict.

In two earlier posts, a member of portmgr@, and someone else described
how the change was also meant to prevent some build errors.

>
>How exactly was that wasted time? Surely you don't download and build a port
>you're not going to install?

A number of earlier posters have said that they want to do exactly
that.  I do it myself, to test ports.  But one can also start with the
intention of installing port A, only to later learn that it conflicts
with an already-installed port B, and then, having discovered the
conflict, decide not to install port A after all, in order to keep
port B.  In this case, which happens fairly often, any time spent
before the discovery of the conflict would have been wasted.