Make sure that logind is enabled if requested, make --disable-logind mandatory to disable logind integration

[Karlson2k]

This is alternative version of #1283

This PR:

• Fix silent disable of logind if --enable-logind is requested, but libsystemd is missing
• Really make --enable-logind default (most common scenario nowadays). As this option is enabled by default, the help string is changed to --disable-logind (no parameter means the same as --enable-logind).

Note: for configure the following parameters are treated equally:

• --enable-logind and --enable-logind=yes
• --disable-logind and --enable-logind=no

[alejandro-colomar]

Cc: @lslebodn

Please review and let me know if you're okay with it.

[Karlson2k]

There are CI failures related to this change.
Actually, both of them are reflecting what I said previously about "autodetect by default or follow explicit instructions".
Looks like both failures here and here are from make distcheck.
distcheck makes number of checks, including unpacking, running configure without parameters. Autotools assume that configure should adapt build to the current system when used without parameters.
Now, libsystemd is required to run make distcheck. Not nice.

[Karlson2k]

As I wrote earlier, autotools use non-interactive approach.
It is assumed that ./configure && make && make install should be enough to build any package. The user must not provide one option and then another option interactively, if standard environment is used.

This is a basis of autotools.
See autoconf documentation:

• autoconf manual
• automake manual: ... all the installer has to do is to unpack the package, run ./configure && make && make install, and repeat with the next package to install.

I strongly recommend to reconsider the approach.

Using autotools in the way orthogonal to autotools ideas will generate more problems then the preferred way.
This is a bad idea.
From automake manual:

Autotools will only be useful if you do accept the concepts of the GNU Build System. People who have their own idea of how a build system should work will feel frustrated by the Autotools.

So unless you switched to another build system, it is better to adhere to autotools ideas.

[Karlson2k]

Autotools are very flexible.
They can be hacked to be used in the way not originally designed for.

make distcheck can be hacked, but it would be not a real "check" as special parameters are used.
I added AM_DISTCHECK_CONFIGURE_FLAGS variable, but this is not recommended:

Developers are encouraged to strive to make their code buildable without requiring any special configure option; thus, in general, you shouldn’t define AM_DISTCHECK_CONFIGURE_FLAGS.

Even your own CI/CD system assumes that ./configure without parameters automatically produces configuration suitable to the test system.

Just a for a single parameter, I have to hack three items:

• autogen.sh:

  shadow/autogen.sh

  Line 21 in 3472e36

  --disable-logind \

• root Makefile.am:

  shadow/Makefile.am

  Line 4 in 3472e36

  AM_DISTCHECK_CONFIGURE_FLAGS = --disable-logind

• runner.yml:

  shadow/.github/workflows/runner.yml

  Line 65 in 3472e36

  ./configure --disable-logind

Imagine that you will remove other automatic detections. For each (or most of) removed detection you will need to add more parameters in at least three items. Then something could be changed in defaults and you will need to reflect again all changes in three places.
Moreover, CI/CD may need different configuration compared to make distcheck. It does not look maintainable.

I strongly recommend to use my original PR #1283. That PR does not need any hacks, because autotools work as expected.
Package maintainers will get strong guarantee that requested options will be forced (or failed early) and not ignored.
In other situations ./configure will just work without extra effort. As it should.

All use-cases are covered by #1283 in a better way. It is perfectly maintainable and work in the way that people expect from autotools build system.

[alejandro-colomar]

Autotools are very flexible. They can be hacked to be used in the way not originally designed for.

make distcheck can be hacked, but it would be not a real "check" as special parameters are used. I added AM_DISTCHECK_CONFIGURE_FLAGS variable, but this is not recommended:

Developers are encouraged to strive to make their code buildable without requiring any special configure option; thus, in general, you shouldn’t define AM_DISTCHECK_CONFIGURE_FLAGS.

Even your own CI/CD system assumes that ./configure without parameters automatically produces configuration suitable to the test system.

Just a for a single parameter, I have to hack three items:

* autogen.sh: https://github.com/shadow-maint/shadow/blob/3472e36833e0b77efb62144cb32c7bffcb77ecbc/autogen.sh#L21

* root Makefile.am: https://github.com/shadow-maint/shadow/blob/3472e36833e0b77efb62144cb32c7bffcb77ecbc/Makefile.am#L4

* runner.yml: https://github.com/shadow-maint/shadow/blob/3472e36833e0b77efb62144cb32c7bffcb77ecbc/.github/workflows/runner.yml#L65

When touching default flags, I usually grep for all such flags, so I'd find all three places and update them. I'm used to doing the same for changing dependencies in the build system, where we need to update all images to install them. Not too bad.

Imagine that you will remove other automatic detections. For each (or most of) removed detection you will need to add more parameters in at least three items. Then something could be changed in defaults and you will need to reflect again all changes in three places. Moreover, CI/CD may need different configuration compared to make distcheck. It does not look maintainable.

I strongly recommend to use my original PR #1283. That PR does not need any hacks, because autotools work as expected. Package maintainers will get strong guarantee that requested options will be forced (or failed early) and not ignored. In other situations ./configure will just work without extra effort. As it should.

All use-cases are covered by #1283 in a better way. It is perfectly maintainable and work in the way that people expect from autotools build system.

I think I prefer the hacked distcheck. @lslebodn, any opinions?

[alejandro-colomar]

@Karlson2k

I've been thinking about what I do in pure-Makefile projects. There, make distcheck does (the equivalent of) $(MAKE) && $(MAKE) install (we don't have ./configure), which means it inherits whatever was passed in the command line.

How about make distcheck inheriting the flags passed to ./configure, so that it uses them again inside? Is that feasible?

[Karlson2k]

Imagine that you will remove other automatic detections. For each (or most of) removed detection you will need to add more parameters in at least three items. Then something could be changed in defaults and you will need to reflect again all changes in three places. Moreover, CI/CD may need different configuration compared to make distcheck. It does not look maintainable.
I strongly recommend to use my original PR #1283. That PR does not need any hacks, because autotools work as expected. Package maintainers will get strong guarantee that requested options will be forced (or failed early) and not ignored. In other situations ./configure will just work without extra effort. As it should.
All use-cases are covered by #1283 in a better way. It is perfectly maintainable and work in the way that people expect from autotools build system.

I think I prefer the hacked distcheck. @lslebodn, any opinions?

I can only repeat myself: when you use the build system in the way it was not designed to, by adding a number of hacks, it becomes fragile and will need much more maintenance work compared to normal use.

I still very strongly recommend to choose my original PR #1283. It covers all the needs of shadow maintainers, distributions packages maintainers and new contributors without any hacks and in the best possible way.

[Karlson2k]

@Karlson2k

I've been thinking about what I do in pure-Makefile projects.

Pure Makefile project is possible, but much less easy to handle. You will loose portability, especially regarding dynamic libraries as they are handled very differently on various systems.
When limiting to GNU systems only, it is doable, but, again, less convenient.

There, make distcheck does (the equivalent of) $(MAKE) && $(MAKE) install (we don't have ./configure), which means it inherits whatever was passed in the command line.

First of all, make distcheck is doing more.
It checks out-of-tree builds (not possible with pure makefile - one more disadvantage to count), checks cleanups (must be manually handled with pure makefile) and performs some other checks.

How about make distcheck inheriting the flags passed to ./configure, so that it uses them again inside? Is that feasible?

This is an absolutely wrong idea.
make distcheck is checking whether the build system works in general. It should work on any supported system.
If you pass some special flags than it will check only one specific system.

Pure makefiles builds are not configured by flags, they are typically configured by variables override, like make USE_UTMPX_INTERFACE=y.
Even with autoconf/automake projects, some variables are passed from configure to makefiles (and can be overridden at the build stage). CFLAGS="-Wall -Wextra -O2" CC=gcc-14 ./configure and then make CFLAGS="-Wall -O0 -ggdb3".
Even better to specify variables as configure parameters, like ./configure CFLAGS="-Wall -Wextra -O2" CC=gcc-14 then with automatic re-configure they will be used again.

[alejandro-colomar]

@Karlson2k
I've been thinking about what I do in pure-Makefile projects.

Pure Makefile project is possible, but much less easy to handle. You will loose portability, especially regarding dynamic libraries as they are handled very differently on various systems. When limiting to GNU systems only, it is doable, but, again, less convenient.

No, a Makefile is more convenient to me. Autotools is kept here as a deference to distro maintainers, but certainly not for making my life as a programmer easier.

I can write portable GNU Makefiles. As long as you port GNU Make to other POSIX systems, I can work there just fine (and more fine than with autotools).

Your experience and mine are very different.

There, make distcheck does (the equivalent of) $(MAKE) && $(MAKE) install (we don't have ./configure), which means it inherits whatever was passed in the command line.

First of all, make distcheck is doing more. It checks out-of-tree builds (not possible with pure makefile - one more disadvantage to count), checks cleanups (must be manually handled with pure makefile) and performs some other checks.

Of course it does more. But it does that, among the other things.

How about make distcheck inheriting the flags passed to ./configure, so that it uses them again inside? Is that feasible?

This is an absolutely wrong idea. make distcheck is checking whether the build system works in general. It should work on any supported system. If you pass some special flags than it will check only one specific system.

make distcheck can only check that the buiold system works on the current system. There's no magic that will tell you if it will work on any other systems.

In fact, it would make more sense to inherit the configure flags, as it would allow testing various configurations deeply on the same system.

Pure makefiles builds are not configured by flags, they are typically configured by variables override, like make USE_UTMPX_INTERFACE=y.

Yes. That's what I was talking about.

[alejandro-colomar]

It checks out-of-tree builds (not possible with pure makefile - one more disadvantage to count)

Wait, what? I write Makefiles that only build out of tree.

Go check the Linux man-pages project build system:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/GNUmakefile

[lslebodn]

Feature-vise LGTM.

Few tiny comments inline and BTW 1st commit fac8f697e58bc7e99a76f8f598eb17ffec24e71c in the patch set is not needed because help string is changed later commit anyway.

[lslebodn]

make distcheck can be hacked, but it would be not a real "check" as special parameters are used. I added AM_DISTCHECK_CONFIGURE_FLAGS variable, but this is not recommended:

Developers are encouraged to strive to make their code buildable without requiring any special configure option; thus, in general, you shouldn’t define AM_DISTCHECK_CONFIGURE_FLAGS.

@Karlson2k I do not interpret it as something which is not recommended. I read it as one should install all recommended dependencies to run make distcheck

BTW this is exactly the same case as with running "make distcheck" without libbsd installed which is enabled by default in configure but optional build dependency

• shadow/configure.ac

  Lines 206 to 208 in 1f617f8

  	AC_ARG_WITH([libbsd],
  	[AS_HELP_STRING([--with-libbsd], [use libbsd support @<:@default=yes if found@:>@])],
  	[with_libbsd=$withval], [with_libbsd=yes])

sh$ ls -l /usr/lib64/libbs*
ls: cannot access '/usr/lib64/libbs*': No such file or directory

sh$  make distcheck -j16 V=0
//snip
checking for crypt in -lcrypt... yes
checking for library containing readpassphrase... no
configure: error: readpassphrase() is missing, either from libc or libbsd
make: *** [Makefile:700: distcheck] Error 1

So one can install either libbsd to make it pass or to use DISTCHECK_CONFIGURE_FLAGS

sh$ time make distcheck DISTCHECK_CONFIGURE_FLAGS="--without-libbsd" -j16 |& tail
make[2]: Leaving directory '/root/shadow/shadow-4.18.0/_build/sub'
rm -f config.status config.cache config.log configure.lineno config.status.lineno
rm -f Makefile
make[1]: Leaving directory '/root/shadow/shadow-4.18.0/_build/sub'
if test -d "shadow-4.18.0"; then find "shadow-4.18.0" -type d ! -perm -700 -exec chmod u+rwx {} ';' ; rm -rf "shadow-4.18.0" || { sleep 5 && rm -rf "shadow-4.18.0"; }; else :; fi
===============================================
shadow-4.18.0 archives ready for distribution: 
shadow-4.18.0.tar.gz
shadow-4.18.0.tar.xz
===============================================

real    1m26.953s
user    2m58.277s
sys     0m44.294s

Using AM_DISTCHECK_CONFIGURE_FLAGS = --disable-logind is OK or one should install libsystemd-dev in
.github/actions/install-dependencies/action.yml in the same way as other recommended dependency libbsd-dev is installed there

• shadow/.github/actions/install-dependencies/action.yml

  Line 25 in 1f617f8

  sudo apt-get -y install ubuntu-dev-tools automake autopoint xsltproc gettext expect libtool libbsd-dev libltdl-dev pkgconf

[Karlson2k]

make distcheck can be hacked, but it would be not a real "check" as special parameters are used. I added AM_DISTCHECK_CONFIGURE_FLAGS variable, but this is not recommended:

Developers are encouraged to strive to make their code buildable without requiring any special configure option; thus, in general, you shouldn’t define AM_DISTCHECK_CONFIGURE_FLAGS.

@Karlson2k I do not interpret it as something which is not recommended. I read it as one should install all recommended dependencies to run make distcheck

Please point where it is written that "recommended" dependencies must be installed to run make distcheck.
It perfectly makes sense to install required dependencies. No doubt, you cannot build the package without required dependencies.
But optional dependencies must remain optional. Otherwise it is like forcing to install libsystemd.

[Karlson2k]

It checks out-of-tree builds (not possible with pure makefile - one more disadvantage to count)

Wait, what? I write Makefiles that only build out of tree.

Go check the Linux man-pages project build system: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/GNUmakefile

Yes, if you want to loose another portability level and switch to GNU-make-only .

[Karlson2k]

@alejandro-colomar Looks like you are trying to project kernel techniques to the user-space.

It is different. Kernel is self-contained, has no dependencies (just tools to compile), should not adapt to the environment (except build tools and configuration set by user directly or via locally-built tools). You can easily require GNU make only, GCC or clang only, binutils.

The apps and libs needs another approach. They should adapt to different environment and be portable in general. bmake (or smake) could be system default make, for example.

[Karlson2k]

BTW, bash could be not available. sed, awk, grep, find could be non-GNU. The list could be further extended.

[alejandro-colomar]

It checks out-of-tree builds (not possible with pure makefile - one more disadvantage to count)

Wait, what? I write Makefiles that only build out of tree.
Go check the Linux man-pages project build system: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/GNUmakefile

Yes, if you want to loose another portability level and switch to GNU-make-only .

This is not loosing portability. Finding a system where GNU Make is not available is not an easy task.

Quoting the maintainer of GNU Make:

https://make.mad-scientist.net/papers/rules-of-makefiles/

Rules of Makefiles

[...]

1.  Use GNU make.

    Don’t hassle with writing portable makefiles, use a portable make instead! 

[alejandro-colomar]

@alejandro-colomar Looks like you are trying to project kernel techniques to the user-space.

No. The man-pages are not the kernel. They are a user-space project.

I've also written very similar build systems for C libraries with dependencies.

The apps and libs needs another approach. They should adapt to different environment and be portable in general. bmake (or smake) could be system default make, for example.

The system make is unimportant. GNU make is always available, even if not part of the base system.

[alejandro-colomar]

BTW, bash could be not available. sed, awk, grep, find could be non-GNU. The list could be further extended.

All systems, including the BSDs have bash, AFAIK. It's just an extra package that's not part of the base system. But packagers can perfectly use bash, GNU make, and whatever they need (an OpenBSD maintainer told me it's usual practice for them).

[Karlson2k]

BTW, bash could be not available. sed, awk, grep, find could be non-GNU. The list could be further extended.

All systems, including the BSDs have bash, AFAIK. It's just an extra package that's not part of the base system. But packagers can perfectly use bash, GNU make, and whatever they need (an OpenBSD maintainer told me it's usual practice for them).

The best for the user is very basic set of dependencies, which is always available (when build environment is present).
The more non-basic dependencies the application need, the less attractive it becomes to the users, as it is becomes longer to build (even with automated process), longer to test.

It is up to you what you do with the package that your are maintaining.
Maybe it becomes too inconvenient for others and then users will switch to some fork. Or maybe not.

[Karlson2k]

All systems, including the BSDs have bash, AFAIK. It's just an extra package that's not part of the base system.

"Just an extra package" means pulling the package together with dependencies. The multiply it for every build, for every container which is used to build, for every distribution and so on. You will be surprised how large could be this number. It is waste of time, resources and energy.
Also is it more maintenance burden for distribution package maintainers.

Is it doable? Yes.
Is it good for others? No.

[alejandro-colomar]

BTW, bash could be not available. sed, awk, grep, find could be non-GNU. The list could be further extended.

All systems, including the BSDs have bash, AFAIK. It's just an extra package that's not part of the base system. But packagers can perfectly use bash, GNU make, and whatever they need (an OpenBSD maintainer told me it's usual practice for them).

The best for the user is very basic set of dependencies, which is always available (when build environment is present). The more non-basic dependencies the application need, the less attractive it becomes to the users, as it is becomes longer to build (even with automated process), longer to test.

On the other hand, these scripts will be safer, as the less-basic tools allow writing code that is more readable, and easier to maintain.

As always, it comes down to portability vs safety, and I choose safety.

[Karlson2k]

On the other hand, these scripts will be safer, as the more complex tools allow writing code that is more readable, and easier to maintain.

As always, it comes down to portability vs safety, and I choose safety.

It does not mean that others will use the same weighting.

The risk of manual management of custom build system is much higher that billions times tested standard build system. So it is much safer to use the standard, well tested approach than to re-invent the wheel.

[alejandro-colomar]

On the other hand, these scripts will be safer, as the more complex tools allow writing code that is more readable, and easier to maintain.
As always, it comes down to portability vs safety, and I choose safety.

It does not mean that others will use the same weighting.

I'm not responsible for the safety of others' systems. If they want to break their own systems, they're free to do it.

The risk of manual management of custom build system is much higher that billions times tested standard build system. So it is much safer to use the standard, well tested approach than to re-invent the wheel.

I've found so many bugs in the build system of this project.

The Linux man-pages build system works like a charm.

Huh?

BTW, make(1) is a POSIX standard, but autotools isn't. Are you sure writing Makefiles is unsafe? Many projects rely entirely on it.

[Karlson2k]

On the other hand, these scripts will be safer, as the more complex tools allow writing code that is more readable, and easier to maintain.
As always, it comes down to portability vs safety, and I choose safety.

It does not mean that others will use the same weighting.

I'm not responsible for the safety of others' systems. If they want to break their own systems, they're free to do it.

Are you talking as shadow co-maintainer?

The risk of manual management of custom build system is much higher that billions times tested standard build system. So it is much safer to use the standard, well tested approach than to re-invent the wheel.

I've found so many bugs in the build system of this project.

And how many of them were security-related?

The Linux man-pages build system works like a charm.

Huh?

Does it always work perfectly?
How many man-hours (man-years) were invested into it to make it work like it works now?
How deeply it should adapt to the presence of the external libraries? Does it work with variable set of external headers?

BTW, make(1) is a POSIX standard, but autotools isn't. Are you sure writing Makefiles is unsafe? Many projects rely entirely on it.

Yes, make is POSIX, but GNU makefiles are not.

However, you do not need to install autotools to build the package as soon as you make a tarball. Autotools uses POSIX standard utilities to build packages on many systems, including not-fullt-POSIX compatible and takes care about portability and compatibility.

You are ignoring POSIX (and other standards) everywhere, why it is an argument now?

[lslebodn]

Please point where it is written that "recommended" dependencies must be installed to run make distcheck.

Developers are encouraged is a positive sentence. it does not say "it is NOT RECOMMENDED"
Moreover, current code pass the recommendation: make their code buildable without requiring any special configure option

Maintainer can install all optional dependencies enabled by default (not just sytemd also libbsd), for creating dist tarball.
They needn't pass "special configure options." in such case)

But they still have a possibility to run "make dist" without installed extra dependencies. They can
run make dist DISTCHECK_CONFIGURE_FLAGS="--disable-${optiona-feature} # for all optional configure features"

It perfectly makes sense to install required dependencies. No doubt, you cannot build the package without required dependencies.
But optional dependencies must remain optional. Otherwise it is like forcing to install libsystemd.

Based on your interpretation, one should remove libbsd-dev from .github/actions/install-dependencies/action.yml
as well because it is optional dependency.

BTW you forgot to quote other part from DISTCHECK_CONFIGURE_FLAGS in automake documentation
where they mention about valid use-caes

• https://www.gnu.org/software/automake/manual/html_node/DISTCHECK_005fCONFIGURE_005fFLAGS.html

GNU m4 offers an example of when its use is justified, however.

GNU m4 configures by default with its experimental and seldom used ‘changeword’ feature disabled;
so in this case it is useful to have make distcheck run configure with the --with-changeword option,
to ensure that the code for changeword support still compiles correctly.

GNU m4 also employs the AM_DISTCHECK_CONFIGURE_FLAGS variable to stress-test the use of --program-prefix=g,
since at one point the m4 build system had a bug where make installcheck was wrongly assuming
it could blindly test ‘m4’, rather than the just-installed ‘gm4’.

Anyway; lets return back to the MR. There is not ideal build system. Each one has pros and cons.

Extra dependency mostly affect CI. Failures in CI are solved by AM_DISTCHECK_CONFIGURE_FLAGS.
TYVM for that

Few related question:

• shall we reconsider whether optional feature"logind" should be enable by default? AM_DISTCHECK_CONFIGURE_FLAGS needn't be use with default no
• do we need to disable all "optional dependencies" in AM_DISTCHECK_CONFIGURE_FLAGS by default? (e.g. --without-libbsd)
• do we want to install all "optional dependencies" in github action?
• shall we test code in CI with libsystemd-dev installed?

[alejandro-colomar]

On the other hand, these scripts will be safer, as the more complex tools allow writing code that is more readable, and easier to maintain.
As always, it comes down to portability vs safety, and I choose safety.

It does not mean that others will use the same weighting.

I'm not responsible for the safety of others' systems. If they want to break their own systems, they're free to do it.

Are you talking as shadow co-maintainer?

That's irrelevant. I'm not responsible for the safety of systems that don't use shadow-utils.

The risk of manual management of custom build system is much higher that billions times tested standard build system. So it is much safer to use the standard, well tested approach than to re-invent the wheel.

I've found so many bugs in the build system of this project.

And how many of them were security-related?

Probably none, but you never know for sure.

The Linux man-pages build system works like a charm.
Huh?

Does it always work perfectly?

Very much. And when there's a minor bug, the fix is trivial. It works much better than the build system of shadow-utils, by orders of magnitude.

How many man-hours (man-years) were invested into it to make it work like it works now?

Very very many. That goes for everything that tries to be best-in-class, of course.

But it scales quite well. I can almost paste that build system into new projects, and use it out of the box with minor changes.

How deeply it should adapt to the presence of the external libraries?

Well, I guess. I didn't find issues so far.

Does it work with variable set of external headers?

The projects I use don't have variable dependencies. But it would be pretty easy to add them, yes.

It wouldn't be much different from the tests that I run at the moment for compiler features.

BTW, make(1) is a POSIX standard, but autotools isn't. Are you sure writing Makefiles is unsafe? Many projects rely entirely on it.

Yes, make is POSIX, but GNU makefiles are not.

However, you do not need to install autotools to build the package as soon as you make a tarball. Autotools uses POSIX standard utilities to build packages on many systems, including not-fullt-POSIX compatible and takes care about portability and compatibility.

The code is written using autotools, so regardless of what runs on the target machine, the safety concerns during packaging are still there. The Makefiles generated by autotools aren't magically safe.

You are ignoring POSIX (and other standards) everywhere, why it is an argument now?

You mentioned "standards". BTW, I don't ignore POSIX. I selectively decide when I don't need to care about it, which is different.

[Karlson2k]

Looks like you decided already so it does not make sense to give you any arguments.

Good luck.
I may only suggest you to check first with the small part to see weather your "simple compact build system" code will be really simple and really compact.
And find how to nicely build shared and static libraries (which should not be a big problem when you are limited to GNU systems).
And keep in mind that any custom build systems are less welcomed by downstream package maintainers.

[Karlson2k]

Maintainer can install all optional dependencies enabled by default (not just sytemd also libbsd), for creating dist tarball. They needn't pass "special configure options." in such case)

But they still have a possibility to run "make dist" without installed extra dependencies. They can run make dist DISTCHECK_CONFIGURE_FLAGS="--disable-${optiona-feature} # for all optional configure features"

Which does not make sense as make distcheck must just work, without such workarounds.

It perfectly makes sense to install required dependencies. No doubt, you cannot build the package without required dependencies.
But optional dependencies must remain optional. Otherwise it is like forcing to install libsystemd.

Based on your interpretation, one should remove libbsd-dev from .github/actions/install-dependencies/action.yml as well because it is optional dependency.

Probably yes.

BTW you forgot to quote other part from DISTCHECK_CONFIGURE_FLAGS in automake documentation where they mention about valid use-caes

• https://www.gnu.org/software/automake/manual/html_node/DISTCHECK_005fCONFIGURE_005fFLAGS.html

GNU m4 offers an example of when its use is justified, however.
GNU m4 configures by default with its experimental and seldom used ‘changeword’ feature disabled;
so in this case it is useful to have make distcheck run configure with the --with-changeword option,
to ensure that the code for changeword support still compiles correctly.
GNU m4 also employs the AM_DISTCHECK_CONFIGURE_FLAGS variable to stress-test the use of --program-prefix=g,
since at one point the m4 build system had a bug where make installcheck was wrongly assuming
it could blindly test ‘m4’, rather than the just-installed ‘gm4’.

Do you see any similarity between these two cases?

• shadow cannot be build with default settings
• m4 checks wrong binary

I don't.

Anyway; lets return back to the MR. There is not ideal build system. Each one has pros and cons.

Extra dependency mostly affect CI. Failures in CI are solved by AM_DISTCHECK_CONFIGURE_FLAGS. TYVM for that

Few related question:

• shall we reconsider whether optional feature"logind" should be enable by default? AM_DISTCHECK_CONFIGURE_FLAGS needn't be use with default no
• do we need to disable all "optional dependencies" in AM_DISTCHECK_CONFIGURE_FLAGS by default? (e.g. --without-libbsd)
• do we want to install all "optional dependencies" in github action?
• shall we test code in CI with libsystemd-dev installed?

As my arguments are collectively ignored and just selectively answered, sometimes based only on "I like another solution, because I prefer it", I'm not going to contribute my time anymore in such discussions.

[alejandro-colomar]

@Karlson2k

Please don't tell me what code will be easier for me to maintain.

Would you mind going back on-topic and discuss the issues raised by @lslebodn ?

[Karlson2k]

@Karlson2k

Please don't suggest me what code will be easier for me to maintain.

Would you mind going back on-topic and discuss the issues raised by @lslebodn ?

It is all yours.

I may close my PRs by myself if you wish.

[alejandro-colomar]

@Karlson2k
Please don't suggest me what code will be easier for me to maintain.
Would you mind going back on-topic and discuss the issues raised by @lslebodn ?

It is all yours.

I may close my PRs by myself if you wish.

I welcome your code contributions, but not that you go off-topic and tell me how much portability we should write, or how easy your favourite language is and how hard mine is.

[Karlson2k]

I had an impression that off-topic was started by you.

Anyway, the PR has been updated with extra spaces in error message.

[alejandro-colomar]

I had an impression that off-topic was started by you.

I don't think so. I was mentioning what I do, because that's what we could do here. But okay, let's stop both.

Anyway, the PR has been updated with extra spaces in error message.

Thanks!

[Karlson2k]

The PR has been updated with libsystemd-dev in .github/actions/install-dependencies/action.yml as now it is critical to have it on all major build runners.

[alejandro-colomar]

The PR has been updated with libsystemd-dev in .github/actions/install-dependencies/action.yml as now it is critical to have it on all major build runners.

Can we please inherit the configure flags in the ./configure run within make distcheck?

[Karlson2k]

The PR has been updated with libsystemd-dev in .github/actions/install-dependencies/action.yml as now it is critical to have it on all major build runners.

Can we please inherit the configure flags in the ./configure run within make distcheck?

This seems to be an unrelated change as this PR has been build-tested fine.

[Karlson2k]

Can we please inherit the configure flags in the ./configure run within make distcheck?

Sorry, I find this idea horrible and I do not want to sign by my name a commit with such things. I already crossed the line with what I think is "bad" in my commits and I do not want to go any further.

But you can do it.

1. First option,
   Just add to configure (any line before AC_OUTPUT)

AC_SUBST([ac_configure_args])

And then add to the toplevel Makefile.ac

AM_DISTCHECK_CONFIGURE_FLAGS = $(ac_configure_args)

2. Second option, even shorter, in one step in configure.ac:

AC_SUBST([AM_DISTCHECK_CONFIGURE_FLAGS], ["$ac_configure_args"])

But in this case AM_DISTCHECK_CONFIGURE_FLAGS will be in all makefiles.

3. Third option, the cleanest

AC_SUBST([ac_configure_args])
AM_SUBST_NOTMAKE([ac_configure_args])

In top Makefile.ac

AM_DISTCHECK_CONFIGURE_FLAGS = @ac_configure_args@

[alejandro-colomar]

Can we please inherit the configure flags in the ./configure run within make distcheck?

Sorry, I find this idea horrible and I do not want to sign by my name a commit with such things. I already crossed the line with what I think is "bad" in my commits and I do not want to go any further.

Sounds reasonable.

But you can do it.

1. First option, Just add to configure (any line before AC_OUTPUT)

AC_SUBST([ac_configure_args])

And then add to the toplevel Makefile.ac

AM_DISTCHECK_CONFIGURE_FLAGS = $(ac_configure_args)

2. Second option, even shorter, in one step in configure.ac:

AC_SUBST([AM_DISTCHECK_CONFIGURE_FLAGS], ["$ac_configure_args"])

But in this case AM_DISTCHECK_CONFIGURE_FLAGS will be in all makefiles.

3. Third option, the cleanest

AC_SUBST([ac_configure_args])
AM_SUBST_NOTMAKE([ac_configure_args])

In top Makefile.ac

AM_DISTCHECK_CONFIGURE_FLAGS = @ac_configure_args@

Thanks!

[Karlson2k]

Updated with extended error message.

[alejandro-colomar]

Thanks!