but it is in conflict with the well-established standard way
of how libraries are distributed in Debian.
This is incorrect. Header-only libraries are present in the Debian
archive, such as libboost-dev or libeigen3-dev. A -dev package does
not automatically have an accompanying shlib package.
libeigen3 is -dev only because the entire Eigen library only consists
of heavily templated header files. There is just nothing to put in
a binary package. So this is not a helpful analogy.
libboost-dev depends on a specific version, like libboost1.61-dev,
which depends on components like libboost-chrono1.61-dev, which depends
on libboost-chrono1.61.0, which contains a shared object library.
So these supposed analogies actually support my case: In Debian practice,
a package libfoo-dev either contains a fully functional library implementation
that consists of headers only, or it depends on a package libfoo<n> that
contains the binary without which the headers are incomplete.
This has nothing to do with libgtest-dev being deceptive, but with you
failing to understand how modern integration of GTest with CMake is
supposed to happen in accordance with upstream recommendations.
»you failing to understand« is neither very nice, nor accurate:
before I can fail to understand, I first need to know that there
is something I ought to understand.
So I thank you, Ghis, for your explanations. But I maintain that
the package description of libgtest-dev leaves room for improvement.
- Joachim
