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
