CONFLICTS usage question

Thomas-Martin Seck tmseck-lists at
Sat Jun 19 12:46:46 GMT 2004

* Oliver Eikemeier (eikemeier at

> Thomas-Martin Seck wrote:
> >* Oliver Eikemeier (eikemeier at
> >
> >>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.

Do you mean that we get a "conflicts with ${PKGNAME}" instead of "is
already installed". This is confusing, of course.

> >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
> Nope. See above: you just deinstall and reinstall conflicttest2. No
> FORCE_PKG_REGISTER on the command line involved.

In this case, it luckily makes no difference, the self-conflict shows
up, as described. Sorry for modifying the example.

> >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?

In my opinion should follow the robustness principle: be
liberal with regard to the CONFLICTS pattern and silently discard a
self-conflict (if it is as easy to spot as I think). I think portmgr's
and/or the ports committer's time is simply spent better with improving than with chasing down CONFLICTS bugs in >10000 individual
ports. Don't forget that maintainers are humans and that the ports
system is in general rather liberal.

> >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.

I do not really like the approach taken there, I'm afraid.

> >How about checking whether we have a
> >self-conflict and omit this case:
> >
> >Index:
> >===================================================================
> >RCS file: /home/ncvs/ports/Mk/,v
> >retrieving revision 1.491
> >diff -u -r1.491
> >---	10 Jun 2004 07:30:19 -0000	1.491
> >+++	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?

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.

More information about the freebsd-ports mailing list