Bug#926317: [Debian-iot-maintainers] Bug#926317: Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control
Hello Harald, IIRC, I put this patch in the first place because of compilation errors at the time, the errors were fixed only after patching the cmake script like this. But your bug made me check again and it seems that it's no longer necessary. So I'll remove the patch and push a new package soon. Thanks Le 19-04-04 à 10 h 25, Harald Welte a écrit : > 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 > 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 >
Bug#926317: [Debian-iot-maintainers] Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control
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 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 Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Bug#926317: [Debian-iot-maintainers] Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control
Hello, I'm not sure I understand the problem. 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. Also, in Debian packages, libsystemd0 doesn't have systemd as a dependency. This may be for a reason. I will try and see what happens if you use libyder with libsystemd and without systemd. But besides the probable fact that a journald log will be unavailable if set, I don't think there will be bad consequences. Le 3 avril 2019 06 h 02 min 22 s HAE, Harald Welte a écrit : >Package: libyder-dev >Version: 1.4.4-4 >Severity: normal > >I'm experiencing problems building yder-based applications:, >libyder.pc (after applying debian/cmake.patch) has a Requires.private >to >the pacakge 'systemd'. However, 'systemd' is not listed in the >'Depends' line of debian/control. > >This leads to the absurd situation that I can build + install >libyder-dev, but other yder-using applications will not get past their >cmaake/autoconf step as 'systemd' is not neccessarily installed. > >So at the very least, 'systemd' should be listed in 'Depends'. > >I'm somewhat doubtful about this entire method of using pkg-config >'Requires.private'. It may make sense in the absence of a package >manager. But as we're talking about a Debian package here: >Dependencies >should be tracked at package installation time using dpkg/apt, and not >some pkg-config private mechanism, IMHO. > >Also, I'm not entirely sure why there's a dependency on 'systemd', and >not 'libsystemd' as in the upstream source. The Debian changelog >unfortunately doesn't explain why that cmake.patch is used. > >Thanks in advance. > >-- System Information: >Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable') >Architecture: amd64 (x86_64) >Foreign Architectures: i386 > >Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) >Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), >LANGUAGE=en_US.UTF-8 (charmap=UTF-8) >Shell: /bin/sh linked to /bin/bash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages libyder-dev depends on: >ii libjansson-dev 2.12-1 >ii liborcania-dev 1.2.9-5 >ii libsystemd-dev 241-2 >ii libyder2.0 1.4.4-4 > >libyder-dev recommends no packages. > >libyder-dev suggests no packages. > >-- no debconf information > >___ >Debian-iot-maintainers mailing list >debian-iot-maintain...@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-iot-maintainers
Bug#926317: libyder.pc Requires.private systemd, but systemd not in debian/control
Package: libyder-dev Version: 1.4.4-4 Severity: normal I'm experiencing problems building yder-based applications:, libyder.pc (after applying debian/cmake.patch) has a Requires.private to the pacakge 'systemd'. However, 'systemd' is not listed in the 'Depends' line of debian/control. This leads to the absurd situation that I can build + install libyder-dev, but other yder-using applications will not get past their cmaake/autoconf step as 'systemd' is not neccessarily installed. So at the very least, 'systemd' should be listed in 'Depends'. I'm somewhat doubtful about this entire method of using pkg-config 'Requires.private'. It may make sense in the absence of a package manager. But as we're talking about a Debian package here: Dependencies should be tracked at package installation time using dpkg/apt, and not some pkg-config private mechanism, IMHO. Also, I'm not entirely sure why there's a dependency on 'systemd', and not 'libsystemd' as in the upstream source. The Debian changelog unfortunately doesn't explain why that cmake.patch is used. Thanks in advance. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libyder-dev depends on: ii libjansson-dev 2.12-1 ii liborcania-dev 1.2.9-5 ii libsystemd-dev 241-2 ii libyder2.0 1.4.4-4 libyder-dev recommends no packages. libyder-dev suggests no packages. -- no debconf information
