Bug 1831941

Cross-filed case 02647564 at the Red Hat customer portal.

The problem is that if we backport patch like that, only distribution
tarballs (make dist) created on EL8 will be fixed.  Robert, I suppose you
develop and release some software on EL8, right?

The consequence is that people will be generally confused that ./configure
script from tarballs generated by the same autoconf (v2.69) behaves
sometimes differently.  Did anyone else backport this before?

From the autoconf upstream discussions, v2.70 should be out pretty soon...
Having that in EL8 would be much more useful update.

That said, backports of patches like that have usually negligible effect
in general and are likely to cause more cons than pros.

Yes, I develop and release software using EL8.

As of writing, there must be some Linux distributions patching autoconf, because some FL/OSS projects out there already support --runstatedir (e.g. BIRD, thus likely Debian). I wouldn't bet that autoconf is really releasing pretty soon (there are discussions regarding releasing 2.70 for years now), so we're waiting for 8+ years for 2.70...and on the mailing list the last activity seems to be from March?

While I would be happy about autoconf 2.70, I've doubts that upstream gets a release through the door when looking to the amount of issues revealed by current tests (on the mailing list).

Do you see a chance for this: Rebase to autoconf 2.70 if it gets released in-time for the next minor EL8 release, otherwise backport the desired option, like some other Linux distributions do?

(In reply to Pavel Raiskup from comment #3)
> From the autoconf upstream discussions, v2.70 should be out pretty soon...
> Having that in EL8 would be much more useful update.
> 
> That said, backports of patches like that have usually negligible effect
> in general and are likely to cause more cons than pros.

I see this point, although I'm also wondering what will be the diff and compatibility between v2.69 from April 2012 and v2.70 released 8+ years after.

(In reply to Robert Scheck from comment #4)
> Do you see a chance for this: Rebase to autoconf 2.70 if it gets released
> in-time for the next minor EL8 release, otherwise backport the desired
> option, like some other Linux distributions do?

This looks like a good plan to me, also with a condition that the compatibility looks good -- Patrik, can you take a look what major Linux distros already have this option? I think we should check at least debian, ubuntu, SUSE, Arch.. so we can do some more educated decision when the time comes.

As to my findings, Debian and Ubuntu has this patch backported. While OpenSUSE, and Arch has not, nor can I find any issues/bugs reported regarding this feature.

There is confirmed functionality of what seems to be a single commit backport in Debian (see the link below).

Debian issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647

PR with the backport: https://src.osci.redhat.com/rpms/autoconf/pull-request/3

What's the status of the PR (because it seems to be an internal system of Red Hat)?

It's unfortunate to see that RHEL 8.3 is without the backport (and autoconf 2.70 obviously hasn't been released meanwhile, too)...

For regression testing of this component, the /distribution/rebuild test can be used:

http://pkgs.devel.redhat.com/cgit/tests/distribution/tree/rebuild

1) find out components that are built using autoconf (BuildRequire it)
2) clone test cases parametrized with COMPONENT variable (example: https://tcms.engineering.redhat.com/case/517979/)

A test that specifically tests the --runstatedir is proposed in Fedora now: https://src.fedoraproject.org/rpms/autoconf/pull-request/6

Let me share here in a public comment what all happened in the last few weeks regarding this request.

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.

Hope this explanation helps understanding the decission.

Autoconf2.7x should be now available in EPEL 8 and also EPEL9.
Builds are marked as stable in Bodhi.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8127e13c71
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d12035f336

(In reply to Filip Januš from comment #69)
> Autoconf2.7x should be now available in EPEL 8 and also EPEL9.

Use it like this:

$> sudo yum install autoconf2.7x
$> autoconf27 --version
autoconf (GNU Autoconf) 2.71
...

The autoconf2.7x package containing the required feature has been added to EPEL8 (and EPEL9).
The feature won't be back-ported to autoconf 2.69 on RHEL8 directly due to unexpected ripple effects.

This feature is already available in RHEL9, hence CLOSED/NEXTRELEASE.