Add --with-newgrp/--with-sg to configure.ac

[stoeckmann]

It would be nice to remove more programs and documentations from the building process to stay in sync with su and other tools the majority of users do not want to use anymore.

Also see #999

[alejandro-colomar]

Distros tend to just edit the makefiles to avoid building certain binaries, which is easier. Are these flags going to be actually used?

Also, removal of su(1) is not an option, since util-linux requires PAM, which some people refuse to use. I'd rather improve our su(1) in the hopes that it might eventually be the preferred implementation.

[alejandro-colomar]

• See also util-linux su requires PAM #464.

[alejandro-colomar]

BTW, I researched about why most distros (and especially Debian) prefer su(1) from Debian. In the case of Debian, the old discussions were not based on any facts, but rather wanting to follow other distros, blindly. More recently, the decission was made because the util-linux implementation has some better support for containers and systemd. Nothing that should be important to the average user, AFAIK.

Actually, as an average user, I'd prefer our simpler implementation, as simplicity tends to go together with safety.

[stoeckmann]

Distros tend to just edit the makefiles to avoid building certain binaries, which is easier. Are these flags going to be actually used?

Well, yes, they do:

• Alpine Linux
• Arch Linux
• Gentoo

And if they don't, they get it wrong:

• Arch Linux

Also, removal of su(1) is not an option, since util-linux requires PAM, which some people refuse to use.

As you can see in the links above, su can already be disabled and this configuration feature is used. The lastlog utility is already disabled by default but enabled by distributions again. Why do you keep inconsistent disabling/enabling of few selected tools (and then even with either enable or with, e.g. --enable-lastlog but --with-su)?

[stoeckmann]

It's your way of maintaining projects, I guess:

• Modifying Makefiles and thus circumventing the build system in place is "easier"
• Using a well established su which technically fits better into majority of distributions is "blindly following others"

Didn't know that ignoring the own user base leads to success, but I guess we will see when su loses its --with-su flag for being recognized as superior again and also for simplicity due to better Makefile patches in distributions for people who keep blindly following util-linux.

[alejandro-colomar]

Cc: @thesamesam , @zeha , @dvzrv , @jubalh , @floppym

[zeha]

IIRC autotools projects should use --enable-X to enable festures, so indeed --with-su would be better named --enable-su.
In Debian we have some way of not building or at least ignoring some built stuff. I think we patch the buildsystem and also do other things.

Would certainly be better to have --enable-X flags for these things.

Generally speaking it would also be nice to switch to meson.

[alejandro-colomar]

Would certainly be better to have --enable-X flags for these things.

Okay. Thanks for the feedback.

Generally speaking it would also be nice to switch to meson.

I'd prefer keeping the status quo for now.

[alejandro-colomar]

It's your way of maintaining projects, I guess:

* Modifying Makefiles and thus circumventing the build system in place is "easier"

I didn't say it's my way; but ISTR some distro maintainer having voiced against these flags, and that they do prefer editing the Makefiles.

See #999 (comment).

[alejandro-colomar]

* Using a well established `su` which technically fits better into majority of distributions is "blindly following others"

That came with regressions. The well established su(1) in Debian was ours, actually. Risking regressions in su(1) is too much risk, IMO.

See #999 (comment).