Bug 1831941 - Backport --runstatedir option for configure [NEEDINFO]
Summary: Backport --runstatedir option for configure
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: autoconf
Version: 8.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.3
Assignee: Filip Januš
QA Contact: Martin Kyral
URL:
Whiteboard:
Depends On: 1935653 1937409
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-06 00:45 UTC by Robert Scheck
Modified: 2021-05-05 14:33 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Add support for --runstatedir option and support for @runstatedir@ placeholder. Reason: Backport --runstatedir option for configure, because modern FL/OSS software already relies on @runstatedir@ placeholder. Result: Support for --runstatedir option and support for @runstatedir@ placeholder.
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
kwalker: needinfo? (kwalker)


Attachments (Terms of Use)

Description Robert Scheck 2020-05-06 00:45:10 UTC
Description of problem:
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

Version-Release number of selected component (if applicable):
autoconf-2.69-27.el8.noarch

How reproducible:
See above.

Actual results:
No autoconf support for --runstatedir option and no support for @runstatedir@ placeholder.

Expected results:
Support for --runstatedir option and support for @runstatedir@ placeholder.

Additional info:
Red Hat introduced the whole /run stuff with systemd in general, so let's do it right and complete, please.

Comment 1 Robert Scheck 2020-05-06 17:30:51 UTC
Cross-filed case 02647564 at the Red Hat customer portal.

Comment 3 Pavel Raiskup 2020-05-11 05:15:24 UTC
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.

Comment 4 Robert Scheck 2020-05-11 11:15:11 UTC
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?

Comment 5 Honza Horak 2020-05-12 09:03:00 UTC
(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.

Comment 6 Patrik Novotný 2020-05-19 08:53:30 UTC
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

Comment 7 Patrik Novotný 2020-05-26 11:34:45 UTC
PR with the backport: https://src.osci.redhat.com/rpms/autoconf/pull-request/3

Comment 9 Robert Scheck 2020-10-05 13:04:51 UTC
What's the status of the PR (because it seems to be an internal system of Red Hat)?

Comment 16 Robert Scheck 2020-11-11 22:38:07 UTC
It's unfortunate to see that RHEL 8.3 is without the backport (and autoconf 2.70 obviously hasn't been released meanwhile, too)...

Comment 20 Martin Kyral 2020-12-07 11:16:30 UTC
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/)

Comment 23 Honza Horak 2021-01-15 12:12:25 UTC
A test that specifically tests the --runstatedir is proposed in Fedora now: https://src.fedoraproject.org/rpms/autoconf/pull-request/6

Comment 47 Honza Horak 2021-03-15 17:01:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.