#1091987 physlock: Intends to link against systemd but fails to compile against it

Package:
physlock
Source:
physlock
Description:
lightweight Linux console locking tool
Submitter:
Niels Thykier
Date:
2025-01-03 05:54:02 UTC
Severity:
normal
#1091987#5
Date:
2025-01-03 05:50:12 UTC
From:
To:
Hi,

When doing the NMU for #1089413, I noticed a rebuild (even a "no-change"
rebuild) caused physlock to drop its dependency on libsystemd0.

Based on the changelog 13-1, it seems like it was intended that the
binary would use systemd. However, looking at the code, I find *no*
place where anything defines "HAVE_SYSTEMD" at a C compiler level,
meaning the relevant systemd consuming code in session.c is simply
skipped. I did a test rebuild without the "SILENT" makefile rules and
that confirmed that there is **no** -DHAVE_SYSTEMD via CLI and I cannot
find it defined in any C or H file.

However, the upstream Makefile will link against libsystemd0 by default
due to the `$(lib_systemd_$(HAVE_SYSTEMD))` with `HAVE_SYSTEMD` at a
Makefile level being 1.

My best guess is that 13-1 was compiled with before the default linking
behavior changed to have the linker only link against libraries actually
used.

Either way, the result seems to be unintentional but also beyond what I
should fix in a minimal NMU, so will be leaving that to you as the
maintainer.

Since the existing behavior is to not have the systemd code be active, I
have left it at that in my NMU, since I figured that was the closest to
the status quo.

Best regards,
Niels