CONFLICTS usage question

[Sergey Matveychuk]

Thomas-Martin Seck wrote:

> * Oliver Eikemeier (eikemeier at fillmore-labs.com):
[...]
>>It is feasible. You could check PKGORIGINS or do the 
>>check-already-installed test
>>before check-conflicts, filtering out previous results. The question 
>>remains:
>>Why?
> 
> 
> Well, why not? If the already-installed check is done beforehand, the
> self-conflict message does not show up and the user is not confused.
> 
> If (s)he forces the reinstall, the self-conflict is silently discarded
> and the user is still not confused (at least not by the ports system).
> 
> I definitely think this is worth pursuing.

Believe me, we can't move check-already-installed _before_ 
check-conflicts target.
The reason is:
1) check-already-installed use PLIST.
2) The final PLIST generated in generate-plist target.
3) Maintainers can modify PLIST. So we need genereate-plist after 
pre_install* targets.

So, if we'll move it, we'll brake check-already-installed target. And we 
even don't nitice it! Because of all will seem to be OK: no warning from 
bento.

Do you see, how many side effects may be hiden behind so easy operation?
Do you understand the Oliver's reaction now?

Well, we can move already-installed target _after_ 
check-already-installed. It looks much safer. But we need to think twice 
before too.

I discover a big secret for you :), I know some quite ugly parts in 
bsd.port.mk that I can't change without hundreds or thousands ports 
breakage.

-- 
Sem.