CONFLICTS usage question

[Oliver Eikemeier]

Thomas-Martin Seck wrote:

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

I'm sorry if you feel offended, this was not my intention. I apologize 
for
the harsh tone, but how should I understand

 > [port (deliberately) CONFLICTS with itself]

then?

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

The problem here is what individual maintainers consider to be `a sound
reason'. I had various discussions about PKGORIGIN, why port versions
shouldn't go backwards, why port versions shouldn't mutate depending on
configuration options, why you shouldn't change your port name depending
on configuration options, the list goes on.

Sometimes maintainers are not very cooperative when you tell them you
need stuff a certain way, and demand increasingly complex examples why
this will break certain constructs. This may be personal freedom, but
makes live very hard when you try to write tools that work on the
whole ports tree, only to find out that _some_ ports decide to do
things differently. Back to start, explain, provide examples...

It may be very democratic this way, and may be educational, but it is
lost development time. I would love it when sometimes port maintainer
would just fix their port names and conflicts like *I* need them (yes,
I'm egoistic) and instead use their creativity to provide patches for
the tools I write, or come up with their own. The world isn't that way
in the land of strong code ownership, I know.

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

With `fixable' I meant just adding CONFLICTS to both ports.

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

Yep. I wonder what will break when I do automatic 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).

Seems like you highjacked the thread to discuss something off-topic here.

-Oliver