Package: librnp-dev
Version: 0.18.1-2+b1
Severity: important
Tags: upstream fixed-upstream
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?
