On Mon, Mar 17, 2025 at 11:42:21PM +0000, Stuart Henderson wrote:
> 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.

LGTM, I'd probably name the port and package 'openrdap' to reflect the
project name, but keeping the 'rdap' executable name.  Given the
timeline for both projects I think it makes sense to rename the
executables brought by net/icann-rdap instead.

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

LGTM except for the renaming mentioned above.

My 2 cents,

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



-- 
jca