Linking rnp::librnp fails to configure:

     $ cat > CMakeLists.txt <<'EOT'
     cmake_minimum_required(VERSION 3.16)
     project(p LANGUAGES C)
     find_package(rnp REQUIRED)
     file(WRITE ${CMAKE_BINARY_DIR}/t.c "int main(void){return 0;}")
     add_executable(t ${CMAKE_BINARY_DIR}/t.c)
     target_link_libraries(t PRIVATE rnp::librnp)
     EOT
     $ cmake -S . -B build
     [...]
     CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/rnp/rnp-targets.cmake:71
(set_target_properties):
       The link interface of target "rnp::librnp" contains:

         JSON-C::JSON-C

       but the target was not found.  Possible reasons include:
       [...]
     Call Stack (most recent call first):
       /usr/lib/x86_64-linux-gnu/cmake/rnp/rnp-config.cmake:64 (include)
       CMakeLists.txt:3 (find_package)
     [...]
     CMake Generate step failed.  Build files cannot be regenerated
correctly.

Same with -G Ninja, and it is not a CMake 4 strictness thing: trixie fails
identically with cmake 3.31.6 and librnp-dev 0.17.1-1+b1.

rnp-targets.cmake puts JSON-C::JSON-C, Botan::Botan, BZip2::BZip2 and
ZLIB::ZLIB in the link interface, but rnp-config.cmake has no
find_dependency
call, so none of those four targets exists. pkg-config --libs librnp still
works.

Upstream fixed this in 1a597a67 ("cmake: make librnp properly consumable by
downstream packages"), which is in main but in no release: v0.18.1 was
released
2025-11-21, the commit is from July 2026. It adds the find_dependency calls
and installs the find modules the exported targets need, which 0.18.1's
source
tree already contains (they are simply never installed today).

I tried it here: it cherry-picks onto v0.18.1 with no conflict, and patching
the installed files with what it generates makes find_package succeed
and the
consumer build. One caveat: the find_dependency calls mean a consumer then
needs libbotan-3-dev, libjson-c-dev, zlib1g-dev and libbz2-dev at configure
time (checked one by one), so librnp-dev would have to depend on them, where
today it depends on librnp0 alone.

If you would rather not pull those in, the alternative is to drop the
$<LINK_ONLY:...> entries from the exported interface: rnp::librnp is
declared
SHARED IMPORTED, librnp-dev ships no static library, and librnp.pc
already has
an empty Libs.private, so nothing downstream needs them.

Could you apply one of the two?