[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 #3 from Michael Grimm <trashcan@ellael.org> ---
(In reply to Leo Vandewoestijne from comment #2)

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

If you do mean that people who want dns/knot3 don't want the additional stuff
from dns/knot-resolver, then yes that makes sense regarding dependencies.

I you do mean that people who want dns/knot-resolver do not want the additional
stuff from dns/knot3 then thats really marginal. Only one more dependency of
liburcu, some 26 additional files, because the rest coms from the metaport
dns/knot3-lib

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

True, but I do have running patches that make dns/knot3 like dns/knot-resolver
dependent on dns/knot3-lib. Now, all library files come from one port, only and
pkg doesn't complain any longer about duplicate files.

It is working in my environment for two days now, but I do not have
knot-resolver running yet (still on unbound).

I do need some more fiddeling and modifications, because 'poudriere testport
dns/knot3' still complains about e.g. 'Error: Orphaned: lib/libzscanner.so'
That is understandable because I had to cut pkg-plist down to the files, needed
by dns/knot3 only.

If you do want, I can provide you with diffs against my local/knot3 et al. But
these are no 'git --diff' yet.

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

Except, one makes dns/knot3 AND dns/knot-resolver dependent on dns/knot3-lib
;-)

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

True. But how would one achieve this, if possible at all? I do not have enough
experience with modifying ports.

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

In the meantime I found:

1) poudriere bulk -j xyz dns/knot-resolver dns/knot3 works. But if you 
   do install both packages, they do remove each other leaving you with 
   only one port becomes installed by removing the other. Order doesn't
   matter.

2) I do use metaports for my grouping of relevant ports per jail et al. 
   And here, order doesn't matter. Error message see first comment of mine.

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