On 2025/03/17 22:04, Theo Buehler wrote: > On Mon, Mar 17, 2025 at 09:45:21PM +0100, James Turner wrote: > > Attached is a new port for a RDAP client. My limited searching in ports > > didn't turn one up. My first cargo port as well. > > There's net/rdapper.
I wrote a port for this too alongside the one for rdapper but didn't
think it was really a good fit for us so didn't finish polishing and
send it out.
- poor arch support (only aarch64 amd64 riscv64)
- build on a reasonably fast machine takes over 20 minutes,
which I thought totally excessive for what it is - fetch json over
http, a bit of caching and retries if a server says to delay, follow
referrals, format the output for display
- gobs and gobs of output. for a simple domain lookup (.org -> tucows)
that rdapper displays in 67 lines, icann-rdap comes up with 560 lines
of what to my eyes is poorly formatted output. (with domain name
lookups you can -O gtld-whois for something more sensible, there is
an environment-based mechanism to set that as default, but you
then get no output if you try an ASN/IP lookup)
- ansi colours and UTF8 line drawing characters, even with
LC_CTYPE=c TERM=dumb, that turns into json if you try to pipe it
through less.
(ok rdapper is not great at clean output format either as it also
uses ansi bold sequences on a dumb terminal unless told not to,
but at least it's better, and cleans it up when piped).
> Please add this to the top of the Makefile:
>
> # ring-v0.17 does not support this arch
> NOT_FOR_ARCHS = sparc64
>
> Then I'm basically ok with this.
>
> Things to consider:
>
> Since it's the official ICANN tool, letting it squat a naked rdap
> seems okay although it's a tad generic.
I won't object to importing, but I _would_ prefer to rename the
binaries; firstly as the port is named icann-rdap it makes it
easier to discover the right binary to use; secondly the nicer
go-based client from openrdap.org dating from 2017 (years before
the ICANN one was started) is also just called "rdap".
I didn't look much at the openrdap.org client before (go is a bit
of a turn-off ports-wise), but now I've tried it, actually I like it the
best of the three - cleaner output than both rdapper/icann-rdap, under
a minute to build, and doesn't pull in 80+ p5-* deps. I'll attach a
first cut at a port for that too.
FWIW here's a diff between James' icann-rdap port and mine, not much
different but there are a couple of small things that maybe worth
taking. I hadn't got round to renaming binaries before I decided
to give up on it ;)
diff -uNp -wur icann-rdap/Makefile /usr/ports/net/icann-rdap/Makefile
--- icann-rdap/Makefile Mon Mar 17 19:50:44 2025
+++ /usr/ports/net/icann-rdap/Makefile Mon Feb 3 17:20:27 2025
@@ -1,11 +1,15 @@
-COMMENT = command-line RDAP client
+# ring-v0.17.8 does not support this arch
+NOT_FOR_ARCHS = sparc64
+
+COMMENT = ICANN's client for Registry Data Access Protocol
+
GH_ACCOUNT = icann
GH_PROJECT = icann-rdap
GH_TAGNAME = v0.0.21
-CATEGORIES = net sysutils
+CATEGORIES = net
-# MIT/Apache-2.0
+# either Apache v2.0 or MIT
PERMIT_PACKAGE = Yes
WANTLIB += ${MODCARGO_WANTLIB} crypto m ssl
@@ -14,7 +18,10 @@ MODULES = devel/cargo
CONFIGURE_STYLE = cargo
-MODCARGO_INSTALL_TARGET_PATHS = ./icann-rdap-cli
+SEPARATE_BUILD = Yes
+
+# a server is available too: "icann-rdap-srv"
+MODCARGO_INSTALL_TARGET_PATHS = icann-rdap-cli
.include "crates.inc"
rdap.tgz
Description: application/tar-gz
