CONFLICTS handling (was: CONFLICTS usage question)

[Thomas-Martin Seck]

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

> Thomas-Martin Seck wrote:

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

As a feeble attempt to summarize the discussion so far. I thought about
what I did when I created the conflicts pattern for www/squid{,24}. I
just wrote squid-* and accepted that the port would in the end conflict
with itself and considered this to be OK. This is of course a deliberate
self-conflict. But see my other posts in the original thread about why I
think that bsd.port.mk should not be overly picky about it.

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

I understand that you investigate a lot of time and effort but please
remember: most maintainers don't. Sometimes it is just not easy to
understand why some things are "bad". If a maintainer is expected to
implement things in a certain way, document it extensively and provide
cut-and-pasteable templates and have portlint(1) check it.

To me it seems that you take scepticism as a personal offence. Please
relax, document what you want people to do and communicate it. This
will convince at least me quicker than you might think. And do not give
others the impression that you are right or "more right" than them (even
if you are).

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

It's not that easy, see below.

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

A lot of things will. You need to have a clear concept how to deal with
it, see below.

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

Maybe. I'm just asking you: what is your or portmgr's plan regarding
conflicts outside of bin, sbin, and libexec and non-trivial conflicts in
general? 

Keep in mind that we have two classes of conflicts to deal with:

Most conflicts regard binaries and are often obvious: users usually
have no need to, say, run squid-2.4 and squid-2.5 in parallel so
checking for a conflict and prohibiting the install is OK. Things get
different when completely unrelated packages install binaries with
the same name. I do not have an example but there seems to have been
at least one case, see <http://cr.yp.to/slashpackage/> under "Name
conflicts" where wuftpd and hylafax used to install a sbin/xferstats
utility. How am I as a maintainer supposed to handle that? How shall
I go about other conflicts, e.g. etc/leapsecs.dat? Is there one port
who is allowed to install it to etc/, the other ports must install
it to etc/${PORTNAME}/leapsecs.dat? Or should they install it to
etc/leapsecs.dat.${PORTNAME}? The same applies to binaries, if we stick
to the example above, both wuftpd and hylafax have a valid reason to
install a xferstats utility to sbin. Mutt and Tin have a valid reason to
install an mbox(5) manpage and so on.

There needs to be a tool to check for conflicts and a clear strategy how
to resolve a non-trivial conflict before the port gets committed. You
cannot run around, stick CONFLICTS to ports and be done with it. If you
do not make it clear how things are to be done, maintainers will do
whatever they think is best. And the ports tree will be as inconsistent
as it is now.

So, the only thing I ask for is: if you or portmgr comes up with a
solution, do not feverishly "correct" other peoples ports but hand out
clear guidelines what to do and give me a change to do it right myself.