NUT `configure` script encourages use of non-standard `--sysconfdir` like `/etc/nut`

[jimklimov]

While this was done in NUT this way "forever", it is still an uncommon approach. It also requires the option to be explicitly configured away from the standard default '${prefix}'/etc, otherwise NUT *.conf files fall into an etc dir directly. This may be okay for the default dedicated prefix /usr/local/ups/etc, but not for truly systemic /etc.

This issue contends that it is better to propagate a new option e.g. --confdir='${sysconfdir}/nut' to work out of the box. Maybe with a variable default, being ${sysconfdir} if that value was customized -- for least-surprise approach with existing build configurations and package recipes, and maybe also the default ${sysconfdir} if --prefix was not customized -- to keep /usr/local/ups/etc and also least-surprise. Ideally detect "value present and matching autoconf default" vs. "option actually provided"?..

On a similar note, some distribution policies also require that configuration samples should go elsewhere (e.g. /usr/share/examples/pkgname) but not into active system config location. Currently patches like https://github.com/TritonDataCenter/pkgsrc/blob/trunk/sysutils/ups-nut/patches/patch-conf_Makefile.in are applied to adjust those builds; having a configure-able optional location would be better.

• Loosely related to rpmlint claim that "All non-executable files in /etc should be configuration files." (so resources replaced by the package are not)
• To think: Is it okay or not to ship user-editable samples for upsmon notification and/or upssched handling scripts there, executable or not? I think I saw upssched-cmd or notifyme under /etc/ups or /etc/nut on some systems and reported screenshots, but not sure OTOH if it was per packaging, make install, or end-user setup.

NUT programs, Makefiles and templated scripts/configs would need to be adjusted to use new variable names.