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
(In reply to Michael Grimm from comment #5) This seems like the ideal arrangement. As a long-time user of both knot ports; I'd really like to see this become the path forward. Thanks, Michael. --Chris
I tried your patches several times. And indeed the move of knot-lib entries to LDCONFIG makes a difference. But every time I finalize the port to be perfect, then the same problem re-occurs. And I can't put the finger to the cause (yet). So earlier this week I came to a solution which shares more values - to prevent double maintenance of the two ports. Then when I was comparing the pkg-plist, the only difference are the executables, which are of limited size anyway. And the dependencies seem equal. And so I start to wonder wether it isn't smarter to simply make knot-resolver depend on knot3, and get rid of the knot3-lib port. Then for users who insists not wanting the daemon I theoretically could simply add post-install rm commands, which would make my life and everybody elses a lot easier. Ahead of your previous reply I also was looking how to install everything as not-root, but I haven't tested what happens when kresd:kresd starts using the lib which is knot:knot It's on my radar.
(In reply to Leo Vandewoestijne from comment #8) "And so I start to wonder wether it isn't smarter to simply make knot-resolver depend on knot3, and get rid of the knot3-lib port." ;-) I do opt for that ... "Then for users who insists not wanting the daemon I theoretically could simply add post-install rm commands, which would make my life and everybody elses a lot easier." ... and make that an OPTION, and everyone will be happy, assumingly. Thanks for coming back to that.
(In reply to Leo Vandewoestijne from comment #8) > And so I start to wonder wether it isn't smarter to simply make > knot-resolver depend on knot3, and get rid of the knot3-lib port. > Then for users who insists not wanting the daemon I theoretically > could simply add post-install rm commands, which would make my life > and everybody elses a lot easier. But wait... What if you simply make knot3 which includes BOTH server && client providing options to install either, or both. Isn't that a simpler and a more elegant alternative? :) Thanks! --Chris
Created attachment 252364 [details] knot with all options (In reply to Chris Hutchinson from comment #10) > simply make knot3 which includes BOTH server && client providing options to install either, or both. Isn't that a simpler and a more elegant alternative? :) It's lib (always) + deamon (optional/default) + utils (optional/default). So your suggestion was basically the approach I was aiming for, unaware that generating enable/disable and with/without configure options has improved since last time I tried the same (long ago). While at it, I even made each module optional. IMHO that's great, but not perfect(yet), minor "problem" is that paradoxal selections seem possible. So not fully foolproof, but looks like able to serve every user-demand. And making knot3-lib absolete. Please have a look at this patch, and let me know what you think.
(In reply to Leo Vandewoestijne from comment #11) What I did for testing: #) I created a new port dns/knot3-test made from dns/knot3 and your patch #) I modified my dns/knot-resolver-current port (knot-resolver-6.0.8) by replacing all dns/knot3-lib references in LIB_DEPENDS to dns/knot3-test #) poudriere bulk -j <jail> -C dns/knot-resolver-current dns/knot3-test #) installed both packages in a test jail and started them: MW-test> ps Af PID TT STAT TIME COMMAND 59023 - SsJ 0:00.09 /usr/local/sbin/knotd -c /usr/local/etc/knot/knot.conf -d 59034 - IsJ 0:00.00 daemon: /usr/local/sbin/kresd[59035] (daemon) 59035 - SJ 0:00.04 /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf -n -q /var/run/kresd 59102 - SsJ 0:00.00 daemon: /usr/local/sbin/kres-cache-gc[59103] (daemon) 59103 - SJ 0:00.01 /usr/local/sbin/kres-cache-gc -c /var/run/kresd -d 1000 What I didn't test: Makefile options in various combinations ;-) Conclusion: Both ports can be compiled, installed and run in parallel! Thanks for your efforts, highly appreciated.
My patch perfectly passed tests with poudriere and portclippy. @committer, for clarity -and because I cannot set BLOCK/DEPEND on PR's I didn't open- I crosspost the order of execution: step 1: PR 277332: dns/knot3 - add options / - prepare to replace knot3-lib step 2: PR 277540: dns/knot-resolver - fix rc scripts - abandon use of knot3-lib - upgrade to current version step 3: PR 280626: dns/knot3-lib - delete absolete knot3-lib port
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e2fc32562362f319e2dea0c9310b52a251af6d9e commit e2fc32562362f319e2dea0c9310b52a251af6d9e Author: Leo Vandewoestijne <freebsd@dns.company> AuthorDate: 2024-08-06 09:50:24 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2024-08-07 15:26:49 +0000 dns/knot3: Add options And prepare to replace knot3-lib which will be deprecated. PR: 277332 Reported by: trashcan@ellael.org dns/knot3/Makefile | 148 +++++++++++++++++++++++++++++++++++----------------- dns/knot3/pkg-plist | 57 ++++++++++---------- 2 files changed, 129 insertions(+), 76 deletions(-)
Committed, Thanks!
Just wanted to say thanks, Leo, for taking the time to do this. I'm a long-time knot user, and this is a welcomed change. :) Thanks, Fernando, for tending to this. --Chris