CONFLICTS usage question

[Oliver Eikemeier]

Thomas-Martin Seck wrote:

> * Oliver Eikemeier (eikemeier at fillmore-labs.com):
>
>> Besides that your `workaround' has problems (as stated above), try the
>> attached ports:
>>
>>  cd /usr/ports/misc/conflicttest2
>> do
>>  make clean deinstall reinstall
>> multiple times. Then do
>>  make CONFLICT_WITH_SELF=yes clean deinstall reinstall
>>
>> See the difference? Other examples are possible, but this is probably
>> the most trivial one. Furthermore, you get a different error message,
>> which is confusing for the novice user.
>
> So, let's try to get this discussion less emotional and more technical:
>
> We have a situation where conflicttest-2 has a build dependency on
> conflicttest-1. conflicttest-1 conflicts with itself.

Yep.

> So we want to forcibly reinstall conflicttest-2 and define
> FORCE_PKG_REGISTER.

Nope. See above: you just deinstall and reinstall conflicttest2. No
FORCE_PKG_REGISTER on the command line involved.

> This will in in turn force conflicttest-1 to be
> built and installed, too.
>
> Because conflicttest-1 conflicts with itself, the installation of
> conflicttest-1 fails with "conflicts with itself" which is, admittedly a
> rather confusing, though technically correct message.
>
> If we disable conflicts checking, everything "works", but if
> conflicttest-2 were to conflict with some/port we would not have
> caught and we might have hosed some/port. Not good.

Plus, you have to set DISABLE_CONFLICTS in the above example, which
will just work when conflicttest1 does not conflict with itself.

> So the more interesting problem is: is there a way to make the conflicts
> generation/check immune to the self-conflict problem.

Of course there is, but is it worth the effort? Or, put the other way
around: what will this buy us?

> The way the
> conflicts file is generated is rather primitive: the CONFLICTS pattern
> is fed to ls(1) and that's it.

IMHO this is buggy. See PR 59696 for an improved version.

> How about checking whether we have a
> self-conflict and omit this case:
>
> Index: bsd.port.mk
> ===================================================================
> RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
> retrieving revision 1.491
> diff -u -r1.491 bsd.port.mk
> --- bsd.port.mk	10 Jun 2004 07:30:19 -0000	1.491
> +++ bsd.port.mk	19 Jun 2004 11:42:27 -0000
> @@ -3084,7 +3084,7 @@
>  	@${RM} -f ${WRKDIR}/.CONFLICTS
>  .for conflict in ${CONFLICTS}
>  	@found="`${LS} -d ${PKG_DBDIR}/${conflict} 2>/dev/null || 
> ${TRUE}`"; \
> -	if [ X"$$found" != X"" ]; then \
> +	if [ X"$$found" != X"" -a "$$found" != 
> "${PKG_DBDIR}/${PKGNAME}" ]; then \
>  		${ECHO_CMD} "$$found" >> ${WRKDIR}/.CONFLICTS; \
>  	fi
>  .endfor
>
> (PKGNAME may not coarse enough as the check criterium since we will miss
> the "port conflicts with an older version of itself", but you get the
> idea. Does that sound feasible?)

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?

-Oliver