Re: How to include a toy library in a package?
On Sat, 27 Jun 2020 at 22:33:30 +0200, Peter Wienemann wrote:
> what is the best way to handle a toy library whose only purpose is to
> provide an example library for a test suite?
...
> Since the toy library is never meant to be used by any "normal" code, I
> thought the best location for this library is to install it into the
> same directory where the remaining test suite components are located
I think you are doing the right thing. /usr/libexec/installed-tests/glib
in the libglib2.0-tests package contains another example of a toy library
used in unit tests: most of the tests are plain executables, but a couple
of tests need to load shared libraries containing additional test code,
because they are testing some feature that has specific interactions
with shared libraries.
The /usr/libexec/installed-tests convention is taken from
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests and seems
as good a convention for installed test-suites as any other - I've been
reusing it in non-GNOME components like dbus.
> - package-has-unnecessary-activation-of-ldconfig-trigger
This is emitted when lintian thinks a library is not on the ld.so
search path, but dh_makeshlibs thinks it might be. Either exclude the
test library from dh_makeshlibs processing with dh_makeshlibs -X, or
suppress the lintian tag.
> - shared-library-lacks-prerequisites
If your toy library is so trivial that it genuinely does not have any
prerequisites (from the source code you linked, this does appear to be
the case), then it's appropriate to suppress this tag.
Practically useful shared libraries and loadable modules nearly always
have prerequisites, so the tag usually indicates a problem, but toy
libraries used in testing are sometimes so simple that they genuinely
do not.
smcv
Reply to: