CONFLICTS usage question

Thomas-Martin Seck tmseck-lists at
Fri Jun 18 21:47:59 GMT 2004

* Oliver Eikemeier (eikemeier at

> Am Freitag den, 18. Juni 2004, um 22:30, schrieb Thomas-Martin Seck:
> >* Oliver Eikemeier (eikemeier at
> >
> >>Thomas-Martin Seck wrote:
> >
> >[port (deliberately) CONFLICTS with itself]
> ??? Of course bugs like that won't hinder a port to install.

Yes, that's what I am trying to say.

> >>>>No. You will break installation with FORCE_PKG_REGISTER=yes.
> >>>
> >>
> >>This disables the checks for already installed packages *and*
> >>for conflicting packages, which are disjoint sets. You can
> >>use this to repair files overwritten by a conflicting port
> >>(of course damaging the other port in the process).
> >
> >Maybe, but one /can/ forcibly reinstall a self-conflicting port with
> >FORCE_PKG_REGISTER and DISABLE_CONFLICTS if one is determined to do so.
> Yep. You won't notice when you damage other ports, (which you will
> when you do not use DISABLE_CONFLICTS), but you can do it that way.

I do not and did not say that one should disable conflicts checking by
default. My sole argument is that it can be used as a last resort for
the FORCE_PKG_REGISTER case (I do not think that this is a common usage,
most people use portupgrade to update/reinstall a port I guess).

> Anyway, read if you want to see other uses of 
> and why conflicting with itself is a relly bad idea. CONFLICTS and
> FORCE_PKG_REGISTER deal with different topics.

Please elaborate, since I still fail to see the real problems with self
conflicting and I find the hoops one has to jump through using more or
less awkward glob expressions to avoid it not really elegant. (And no,
the "problem" with FORCE_PKG_REGISTER does not count for me, since it
can be worked around, if really needed. This is a strawman, IMHO.).

> >As an interesting side note: it is amazing how many ports install a
> >${PREFIX}/etc/leapsecs.dat. Where are CONFLICTS when you need them :(
> Which ports are you referring to?

devel/libtai and mail/mess822. sysutils/clockspeed installs leapsecs.dat
to etc/clockspeed; I do not know whether this makes sense at all (i.e.
whether sntpclock would look there for it; I did not look at the code

For the records, the CONFLICTS approach is not too bad, and instead of
bikeshedding over self-conflictness we resp. portmgr@ should tackle the
more subtle conflicts, e.g. the leapsecs.dat conflict or the mbox.5
conflict between mail/mutt and news/tin (my all time favourite). Maybe
the ports cluster could be abused to generate a database of plist files
which could be scanned for duplicates?

More information about the freebsd-ports mailing list