#2905 Re-approval of Change proposal: RPM Macros for Build Flags for F38
Closed: Accepted by churchyard. Opened by zbyszek.

In https://pagure.io/fesco/issue/2805#comment-828733, @tstellar asked us to provide a formal stamp of approval for the changed proposal. Since we already closed the previous ticket, I think it's better to open a new one and do a new vote here.

Proposal: Change proposal: RPM Macros for Build Flags
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags

+1 from me


Metadata Update from @zbyszek:
- Issue assigned to tstellar

I find the design reasonable, and I think the macros will be useful.

I’m not convinced that it should be mandatory to use them whenever a compiler flag is added. The promised greppability improvement seems minor, compared to grepping for optflags and assignments to the *FLAGS environment variables, and there don’t seem to be other benefits other than consistency and convenience. That seems like a lot of compliance squeeze for not much juice.

It seems a package that keeps a single spec file with conditionals for all releases (including EPEL) will need something like this indefinitely to comply with the proposed policy?

%if 0%{?fedora} > 37
%global _pkg_extra_cflags -ffp-contract=off
%global _pkg_extra_cxxflags -ffp-contract=off
%else
export CFLAGS="${CFLAGS-} -ffp-contract=off"
export CXXFLAGS="${CXXFLAGS-} -ffp-contract=off"
%endif

+1 from me on the overall proposal, but an answer to music's question around EPEL would be good

I'm going to vote -1 to prevent auto-approval until we have an answer for what we will do for EPEL.

Also note that %if 0%{?fedora} > 37 will exclude ELN from that conditional, which is probably not intended.

I'm going to vote -1 to prevent auto-approval until we have an answer for what we will do for EPEL.

Whatever the situation is for EPEL, it would also affect Fedora until F37 is end-of-life.

Also note that %if 0%{?fedora} > 37 will exclude ELN from that conditional, which is probably not intended.

You’re right, which makes this an unintentional example of why I don’t like creating the need for this kind of conditional unless there’s a technical reason we have to. Besides adding clutter, they are surprisingly hard to write correctly.

Metadata Update from @bcotton:
- Issue tagged with: meeting

@tstellar how will the flags affect %optflags and ${RPM_OPT_FLAGS}?

APPROVED (+8,0,-1). The change is approved with a slight modification. "The Fedora packaging policy will be updated to require that packages that want to use additional flag use the new macros" will be relaxed to s/require/recommend/ to allow packagers to not use this change if they desire to use the same spec in older Fedora/EL releases.

https://meetbot.fedoraproject.org/fedora-meeting/2022-12-06/fesco.2022-12-06-17.00.html

Metadata Update from @churchyard:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

I am good with the final decision. +1

APPROVED (+9,0,-0).

There has been some new concerns raised with this change. Should we make the following modification: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/244 and/or postpone this until f39 ?

I'm fine with shipping this in F38. The change is effectively dead/unused logic right now anyway, so if we feel like changing the names of the macros, then let's do it now before freeze.

Metadata