[Debian-iot-maintainers] Bug#926317: Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control

[Harald Welte]

Hi Nicolas,

thanks for your response.

On Thu, Apr 04, 2019 at 09:10:10AM -0400, Nicolas Mora wrote:
> Libyder relies on libsystemd to write logs in journald, but it's one of the log output available, like syslog, a file, a callback or the console. But you can use libyder without systemd if you don't use it as log output.

This is great,

but then why do you have the following patch in the yder debian package?

Description: soname is still 2.0, fix PKGCONF_REQ_PRIVATE
Author: Nicolas Mora <mail at babelouest.org>
Index: yder-1.4.4/CMakeLists.txt
===================================================================
--- yder-1.4.4.orig/CMakeLists.txt
+++ yder-1.4.4/CMakeLists.txt
@@ -135,7 +135,7 @@ endif ()
 
 if (WITH_JOURNALD)
   set(PKGCONF_REQ "")
-  set(PKGCONF_REQ_PRIVATE "libsystemd, liborcania")
+  set(PKGCONF_REQ_PRIVATE "systemd, liborcania")
 else ()
   set(PKGCONF_REQ "")
   set(PKGCONF_REQ_PRIVATE "liborcania")

This patch does the *exact opposite* of what you described in your
e-mail.  It causes the libyder.pc contain a Requires.private on
'systemd', and not on 'libsytemd'.

This means you can build + install they libyder + libyder-dev package just fine
on a system without systemd. But then, when you actually want to build any
application against libyder, its autoconf/cmake step will fail as 'systemd.pc' is
not available but listed in Requires.private.

So if you really only need libsystemd, why change from libsystemd to
systemd in the patch above?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)