Add --disable-syslog configure option by FreziDok · Pull Request #1618 · shadow-maint/shadow

FreziDok · 2026-04-28T12:12:57Z

Implements --disable-syslog configuration option, as discussed in #1610

Addresses #1610

It allows build systems like Yocto to disable syslog calls during native builds, preventing log spam on the build host. Addresses shadow-maint#1610 Signed-off-by: Dmitry Sakhonchik <frezidok1@gmail.com>

lslebodn · 2026-04-28T19:32:57Z


+AC_ARG_ENABLE([syslog],
+	[AS_HELP_STRING([--disable-syslog],
+		[disable syslog() calls @<:@default=no@:>@])],


One cause use --disable-syslog --enable-syslog as shorter versions
instead of using --enable-syslog=no

IMHO it is simpler to read "positive flags" in code and in help

WDYT about change?

- [AS_HELP_STRING([--disable-syslog], - [disable syslog() calls @<:@default=no@:>@])], + [AS_HELP_STRING([--enable-syslog], + [enable syslog() calls @<:@default=yes@:>@])],

IMHO it is simpler to read "positive flags" in code and in help

Agree.

WDYT about change?

Sounds reasonable. However, I don't understand much about the build system. Maybe others have other opinions.

Cc: @thesamesam , @Karlson2k , @jubalh

Usually parameter indicated as '--disable-something' when 'something' is enabled by default.
And the opposite: help string is '--enable-something', when 'something' is disabled by default.
Here the default value is 'enabled', it means that logically help string should be '--disable-syslog' (as '--enable-syslog' is no-op in this case).

In other words: seeing '--enable-syslog' in built-in help one may think that syslog is disabled by default and must be enabled explicitly.

Makes a little sense to document parameter '--enable-syslog' which changes nothing, while only '--disable-syslog' changes something and it is not documented explicitly.

For clarity: the help string is wrong. It must be

[AS_HELP_STRING([--disable-syslog], [disable syslog() calls])],

only --enable-something may have optional parameter, like --enable-something=no.
--disable-something is converted automatically to --enable-something=no, while --disable-something=no is reported by configure as an error.

Alternatively, you may use

[AS_HELP_STRING([--disable-syslog], [[disable syslog() calls [enable]]])],

or

[AS_HELP_STRING([--disable-syslog], [[disable syslog() calls [enabled by default]]])],

but I don't think that it will add any clarity.

only --enable-something may have optional parameter

It makes sense, thanks for the correction.

I think

[[disable syslog() calls [enable]]])],

and

[[disable syslog() calls [enabled by default]]])],

are only adding obscurity, because it's hard to understand what is enabled: disable function (means syslog is disabled) or syslog function, so I think your first variant with only [disable syslog() calls])], is the most appropriate.

alejandro-colomar · 2026-04-28T20:47:19Z

@@ -145,6 +145,13 @@ AC_ARG_ENABLE([logind],
 	[enable_logind="yes"]
 )



From the commit message:

Addresses #1610

Please spell that as:

Closes: <https://github.com/shadow-maint/shadow/issues/1610>

Karlson2k · 2026-04-28T20:52:02Z

+AC_ARG_ENABLE([syslog],
+	[AS_HELP_STRING([--disable-syslog],
+		[disable syslog() calls @<:@default=no@:>@])],
+	[enable_syslog="${enableval}"],


Useless assignment.
It is expanded by autoconf to literallly:

enableval="$enable_syslog" enable_syslog="${enableval}"

Could be left empty or added value checking, like

AS_CASE([${enableval}], [yes|no],[:], [AC_MSG_ERROR([wrong parameter value: --enable-syslog=${enableval}])] )

I am not an expert in autoconf, so I just looked at others options like

AC_ARG_ENABLE([lastlog], [AS_HELP_STRING([--enable-lastlog], [enable lastlog @<:@default=no@:>@])], [enable_lastlog="${enableval}"], [enable_lastlog="no"] )

and did the same as there.

Could you please explain what is the difference between them?