Package the Zenoh transport, taking Zenoh itself from Eclipse

[tsaubergine]

Adds libgoby3-zenoh, libgoby3-zenoh-dev and goby3-zenoh, following the MOOS trio, and takes Zenoh itself from Eclipse's Debian repository rather than mirroring it into packages.gobysoft.org.

Pairs with GobySoft/goby3#414 — the branch name matches, so the *-deb-build jobs pick this branch up automatically via the git checkout origin/${CIRCLE_BRANCH} step.

Merge ordering

Merge this only with or after GobySoft/goby3#414. The three .install files name libgoby_zenoh.so.*, usr/include/goby/zenoh/* and goby_zenoh_tool, which only exist once Goby builds them. On its own against today's 3.0 this would fail dh_install.

Where the Zenoh dependency lands

Only in the three new packages. goby3-apps gains a Suggests: goby3-zenoh and nothing more — goby execs goby_zenoh_tool for the goby zenoh action rather than linking against it, so a hard dependency would be wrong.

Build-Depends gains libzenohc-dev and libzenohcpp-dev:native, both restricted to [amd64 arm64]. The build chroots therefore need Eclipse's repository configured; goby3#414 adds that step to the Debian job templates.

amd64 and arm64, not armhf

Eclipse builds libzenohc for all three, and it cross-installs correctly: it is not Multi-Arch: same, so installing it for the host architecture replaces rather than joins the build architecture's, leaving /usr/lib/libzenohc.so as the library being cross-compiled against — which is what a cross build wants, since nothing in Goby links libzenohc for the build architecture.

armhf is excluded for a different and entirely upstream reason. libzenohcpp-dev is Architecture: all — headers, nothing architecture specific — but zenohcxxConfigVersion.cmake hardcodes the pointer size of the machine Eclipse built it on:

if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
  set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()

so CMake refuses the package on any 32-bit build:

Could not find a configuration file for package "zenohcxx" that is
  /usr/lib/cmake/zenohcxx/zenohcxxConfig.cmake, version: 1.10.1 (64bit)

rules gates -Dbuild_zenoh=ON on the target architecture accordingly. This is worth reporting to Eclipse — arch-independent content should not declare itself 64-bit only — and if they fix it, widening this to armhf is a one-word change in each of control and rules.

Two upstream quirks that shaped the rest

• libzenohcpp-dev declares no Depends: at all, so it does not pull in the C library. Both it and libzenohc-dev are named explicitly wherever needed. It also carries no Multi-Arch: foreign despite being Architecture: all, so it cannot satisfy a host-architecture build dependency — hence :native, which is correct here since the headers are identical for every architecture.
• libzenohc's SONAME is unversioned (literally libzenohc.so) and it ships no shlibs file, so dh_shlibdeps can derive no dependency from it. libgoby3-zenoh names libzenohc directly, and rules gives the Zenoh packages the --ignore-missing-info treatment already used for goby3-clang-tool.

Validation

Against a staged install using the Debian libdir layout:

• all 7 .install globs match — library, headers, CMake config and goby_zenoh_tool all land where control says
• all 21 staged Zenoh files are claimed by exactly one package, so nothing dh_install --fail-missing would reject and no double-claim with libgoby3 or libgoby3-dev

Plus dpkg-checkbuilddeps parses and resolves the arch-qualified and :native build dependencies, control parses cleanly at 17 binary packages, and rules parses under make --dry-run on the amd64, arm64 and armhf paths, building Zenoh on the first two only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XzsSmsrcKX6t7n6tLkohjy