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 (3K)