I tried to compile both dns/knot-resolver and dns/knot3 by poudriere: ===> Installing existing package /packages/All/knot-resolver-5.7.0_2.pkg [stable-default-job-02] Installing knot-resolver-5.7.0_2... [stable-default-job-02] `-- Installing knot3-lib-3.3.3_1... pkg-static: knot3-lib-3.3.3_1 conflicts with knot3-3.3.3_1 (installs files into the same place). Problematic file: /usr/local/include/knot/module.h Failed to install the following 1 package(s): /packages/All/knot-resolver-5.7.0_2.pkg *** Error code 1 Stop. Reason (IMHO): 1) dns/knot-resolver is dependet on dns/knot3-lib 2) dns/knot3-lib installs all lib and include files in the very same directories as dns/knot3 3) pkg complains about '(installs files into the same place)' Possible solutions: 1) dns/knot3-lib should store its libraries and includes into a different location as dns/knot3 does 2) dns/knot3-lib provides the library as currently, but make dns/knot3 depend on dns/knot3-lib and just provide the additional functionality of dns/knot3 Have a look at the thread around https://lists.freebsd.org/archives/freebsd-ports/2024-February/005548.html Sorry, but I don't have a solution for that.
*** Bug 277331 has been marked as a duplicate of this bug. ***
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.
(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.
Created attachment 248871 [details] patch for dns/knot3 #) this patch makes dns/knot3 dependent on dns/knot3-lib #) tested with 'poudriere testport' #) running for some days without any glitches
Created attachment 248872 [details] patch for dns/knot3-lib #) this patch makes dns/knot3-lib dependent for both dns/knot-resolver and dns/knot3 #) tested with 'poudriere testport' #) tested with all options set and default options
Please check both patches in your environment. I do have both patches tested as thoroughly as possible. Both modified ports compile with 'poudriere bulk' with default and all options set. Portlint doesn't complain. But I do have to state, that I am not running dns/knot-resolver, yet. Feel free to accept, modify, or neglect both patches ;-) Regards, Michael