Since the --runstatedir option was backported to autoconf, the %configure RPM macro should set this option properly. This has actually caused some issues, due to an upstream bug[1] causing @RUNSTATEDIR@ not to be properly expanded. This upstream issue wouldn't affect us, if runstatedir was properly for each build. Some packages cope with this issue on the per package bases[2], but I believe this should be resolved in the %configure macro itself. More information in the related bug report[3]. [1] https://lists.gnu.org/archive/html/bug-autoconf/2021-03/msg00001.html [2] https://src.fedoraproject.org/rpms/krb5/c/327ebd0b263aa5adaafd83851b8dd9953f984c01?branch=rawhide [3] https://bugzilla.redhat.com/show_bug.cgi?id=1935653
Pull request: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/121
I think this needs to be a Fedora change proposal, to express the benefit. Existing configure scripts only ignores unknown --with/--enable options, they error on failures. So for this change, we would have to rebuild the configure script from source during the build, which is a much larger change.
Is it possible to detect whether the configure script supports the --runstatedir option and supply it conditionally? Within the %configure macro we already do a whole bunch of stuff to the configure script, including modifying it on the fly, so even grepping it for something wouldn't really seem out of place.
(In reply to Jason Tibbitts from comment #3) > Is it possible to detect whether the configure script supports the > --runstatedir option and supply it conditionally? Within the %configure > macro we already do a whole bunch of stuff to the configure script, > including modifying it on the fly, so even grepping it for something > wouldn't really seem out of place. Again, I do not understand why we need to do this, particularly without making the change in Fedora first. Why do we suddenly need this complexity in the middle of the distribution's life-cycle? That part is not clear to me.
From my point of view, this PR isn't able to break %configure macro. Because nowadays %configure macro contains --localstatedir=/var and in autoconf documentation, we can find that runstatedir directly depends on localstatedir (runstatedir is defined as ${localstatedir}/run). So if we add --runstatedir into %configure macro there is nothing new, only we define explicitly runstatedir. it should behave the same, so I don't understand why do we need fedora change? Maybe I overlooked something important but here I don't see the problem.
(In reply to Florian Weimer from comment #4) > Again, I do not understand why we need to do this, particularly without > making the change in Fedora first. Note that I did not say we needed to do this. I was merely speculating on a safe way to do this. I don't have an opinion on this change one way or another as long as it doesn't introduce breakage. > Why do we suddenly need this complexity in the middle of the distribution's > life-cycle? That part is not clear to me. I don't see that this change was proposed for anything other than rawhide, but maybe I'm not looking in the right place.
This seems like a reasonable change for rawhide. I just updated an upstream package assuming that fedora would set this already: https://github.com/lathiat/nss-mdns/commit/df4364ec5b12082b66b7bed9311adbec88b0fd51 It's fine that it doesn't right now, but it would be nice if it did. (motivation: https://bugzilla.redhat.com/show_bug.cgi?id=1471318#c21)
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Fred, Florian and I discussed this issue and we think we see this in stages: - Fedora 38 system-wide change request to use --runstatedir where possible. - Write the redhat-rpm-config change such that it can scan the package configure script to check for runstatedir availaiblity and use it where possible. - Run the mass-prebuild scripts across the distribution to look for failures with the patch to manage issues at the Fedora 38 mass rebuild stage. Packages will be in one of 3 possible states: - Prebuilt configure script without runstatedir support, and we can't pass the option. - We use a prebuilt configure script with a patched autoconf and we have the runstatedir option and can use it. - We don't use the prebuilt configure script and run autoreconf during the build to get runstatedir and can use it. In the last two states we can pass the --runstatedir option to the packages. In the first state we cannot since doing so would fail the build e.g. configure: error: unrecognized option: `--runstatedir=/run'