The impact of the bug #1831941 turned to have negative consequences for depended component(s) -- one component (krb5) stopped building and the impact on runtime in others is not entirely clear, so the SST decided to rather revert this RFE. This bug tracks the reverting itself.

The original RFE was:
--------------------------
Backport --runstatedir option for configure, because modern FL/OSS software already relies on @runstatedir@ placeholder.
 - https://lists.gnu.org/archive/html/autoconf-patches/2013-09/msg00018.html
 - https://www.gnu.org/prep/standards/html_node/Directory-Variables.html


Description of problem:
--------------------------
Copy&pasting reasoning from https://bugzilla.redhat.com/show_bug.cgi?id=1831941#c47:

We originally didn't see any problems to backport this RFE and it seemed quite safe. However, the krb5 package started to fail when being build with autoconf that includes this change.

Further investigation revealed that the krb5 package does handle runstatedir somehow (which is different than what autoconf does with this option) and the check during the krb5 fortunately made the build fail:

  # Sanity check the KDC_RUN_DIR.	
  configured_kdcrundir=`grep KDC_RUN_DIR src/include/osconf.h | awk '{print $NF}'`
  configured_kdcrundir=`eval echo $configured_kdcrundir`
  if test "$configured_kdcrundir" != %{_localstatedir}/run/krb5kdc ; then
    exit 1	
  fi

We tested other packages in RHEL-8 and they were built fine with this change backported. However, we realized that if there was no check like this in the krb5 (even in other packages), the change in runstatedir might not be spotted during build, but the build result will be different.

In short, the issue lays in expanding values -- autoconf does not expand the runstatedir and returns a value "${localstatedir}/something" if defined, so it is up to further building scripts what they do with such value (it should be expanded). If it's not expanded properly, but the "${localstatedir}" is taken as a bash variable (that might be empty), it can easily become just "/something" which might be an issue depending on usage.

Since the real impact of this is unknown here and we're dealing with this change during the RHEL-8 lifetime (when packages are expected to stay compatible), we decided to not include this change to not risk breakage of other RHEL packages or customer applications (not only during build) in RHEL-8.

Since this change is now backported in Fedora, it will be further tested in real scenarios and affected packages will likely adopt (krb5 already did). That way, there is a good chance this feature will be part of RHEL-9 (no promises, it always depends on how it's accepted). That way, even RHEL users will be able to adopt better and there is also not gonna be that big push on backward compatibility as we have currently on updates during RHEL-8.