[Bug 277332] dns/knot-resolver and dns/knot3 are mutually exclusive due to dns/knot3-lib

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277332

--- Comment #2 from Leo Vandewoestijne <freebsd@dns.company> ---
So indeed there is:

 - dns/knot3 : always installs the lib, by itself - not using the dns/knot3-lib
 - dns/knot3-lib : is a metaport of dns/knot3
 - dns/knot-resolver : installs dns/knot3-lib in case there is no dns/knot3

Reason for this is because people who do want knot-resolver often don't want
the entire dns/knot-resolver port (plus all of it's deps.).

So yes, when you 'pkg install dns/knot-resolver' then guesses were made which
it doesn't detect, and so tries to install something that may or may not be
present.

In reverse order:

> Possible solutions #2
is incorrect, as dns/knot3 does NOT depend on dns/knot3-lib

> Possible solutions #1
but IMHO a bad idea, as this would create duplicate libaries, and almost
certainly will create versioning conflict when they are installed using
portupgrade or manually from ports.
Long ago I tried to create this as a possible solution also, without success.

Basically the problem is that there is no way to signal to Knot-DNS to use the
already present lib. Regardless it just installs it, since it (correctly)
expects that it is the only source of it.

So yes, the authoritarian Knot acts maybe a bit authoritarian,
and this construction is the least problematic method to avoid conflict.

Contrary you could also say the 'duplicate path check' is creating a problem of
something that actually isn't a problem.

Question:
Is this error actually always occuring, regardless of the order of install?
Since dns/knot3-lib is a metaport of dns/knot3 I find it odd that it's in
conflict with itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.