CONFLICTS usage question

[Thomas-Martin Seck]

* Oliver Eikemeier (eikemeier at fillmore-labs.com):

> Thomas-Martin Seck wrote:

> >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).
> 
> Ok, the port has a bug that can be worked around. Most people are not
> affected by the bug. So what?
> 
> >>Anyway, read bsd.port.mk if you want to see other uses of
> >>FORCE_PKG_REGISTER
> >>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.).
> 
> Besides that your `workaround' has problems (as stated above), try the
> attached ports:

No attachment there, sorry. I'll try it out.
 
> The point I'm making here is that you are deliberately breaking some
> basic mechanisms of the ports system, not caring about the consequences,
> because it works for you. Have you ever tried to add new features to the
> ports system, only to see that 1% of the ports are failing because they
> use creative solutions or are just too lazy to adhere to the standards?

Oliver, I say this once and for all:

Please do not claim that "I am deliberately breaking something". This is
not correct and I take offence by this. I tried my best to remove
self-conflictness in the squid ports I maintain, so please take a deep
breath before you talk on, will you?

Give me a sound reason why things are as they are and I am silent, trust
me. On the other hand, "explanations" of the kind "I say so and so be
it, infidel" make me ask questions. Sorry, but I did not get any
technical answer beyond "it's bad, you break things, because I say so".

[etc/leapseconds]

> >>Which ports are you referring to?
> >
> >devel/libtai and mail/mess822.
> 
> That should be easily fixable, please send-pr a patch.

If you move away leapsecs.dat from ${PREFIX}/etc, you will probably 
break applications which use libtai. This is not so trivial, I guess.
See below.

This is btw just an examble of the subleties of proper conflicts
checking.

> >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
> >though).
> 
> Does this conflict with anything? Considering the name of the directory I
> wouldn't assume this.

It doesn't conflict, but it does not make sense either. According to
libtai's leapsecs(3), leapsecs.dat *must* be installed to ${PREFIX}/etc/
to take any effect. So its up to the maintainers to coordinate with each
other (or, come to think of they need to check whether the file is
already present and install it as file.portname).

> >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?
> 
> I have a portconflicts tool in my development projects (in fact I
> seeded a development version for testing), but hope to replace it by
> something better. If more ports would play be the rules, testing would
> be simpler and development faster.

Fine.