Latest revision as of 17:03, 13 January 2022

%set_build_flags for %build, %check, and %install phases

Summary

Call %set_build_flags macro automatically at the beginning of the %build, %check, and %install phases of RPM builds in Fedora Linux. This will ensure that the compiler flag environment variables are set for every RPM build.

Owner

Name: Tom Stellard
Email: <tstellar@redhat.com>

Current status

Targeted release: Fedora Linux 36
Last updated: 2022-01-13
devel thread
FESCo issue: #2728
Tracker bug: #2040430
Release notes tracker: <will be not assigned by the Wrangler: not user-facing>

Detailed Description

The %set_build_flags macro exports common environment variables used for building packages:

CFLAGS
CXXFLAGS
FFLAGS
FCFLAGS
LDFLAGS
LT_SYS_LIBRARY_PATH
CC
CXX

These environment variables are set to the compiler flags defined in the system RPM configuration. This macro is currently implicitly called when packages use some of the build system helper macros, like %configure, %cmake, and %meson. However, not all packages use these macros and so some packages do not use the correct compiler flags as required by the Fedora packaging guidelines[1].

This change will be implemented by updating the %__spec_build_pre, %__speck_check_pre, and __spec_install_pre macros in redhat-rpm-config to include %set_build_flags. This will set these environment variables automatically before the %build, %check, and %install phases. See the proposed implementation for more details.

The purpose for making this change in the %check phase is because sometimes test code gets built in the %check phase for unit tests and this will ensure that the application code and its tests are built with the same set of flags. This change is also being made in the %install phase for a similar reason, because sometime code gets built during the install phase.

This change should have no impact on packages that already use %set_build_flags either directly or indirectly through another macro. It also won't impact any package that currently sets these environment variables or modifies any of the %{build*_flags} macros in their %build or %check sections.

Packagers may opt out of this behavior by doing:

   %undefine _auto_set_build_flags

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

Feedback

Based on feedback on the devel list, the following changes were made:

Added %set_build_flags to the %install phase.
Added an opt-out mechanism:

   %undefine _auto_set_build_flags

Benefit to Fedora

This change will ensure that more packages are built using the correct compiler flags, and bring them in compliance with the Fedora packaging guidelines. It will also help improve the security of the distribution as many of the compiler flags help defend against common security attacks.

Scope

Proposal owners:
- Make the necessary changes to redhat-rpm-config.
- Help debug any issues uncovered by this change during the mass rebuild.

Other developers:
- Report bugs to the proposal owner.

Release engineering: #10482

Policies and guidelines: N/A (not needed for this Change)

Trademark approval: N/A (not needed for this Change)

Alignment with Objectives:

Upgrade/compatibility impact

How To Test

This change will be tested by rebuilding packages as part of the mass rebuild.

User Experience

This change will make some packages less susceptible to security exploits.

Dependencies

Contingency Plan

Contingency mechanism: The proposal owner will revert the change in redhat-rpm-config
Contingency deadline: Beta Freeze
Blocks release? No

Documentation

None needed.

Release Notes

@@ Line 1: / Line 1: @@
+<!--
 {{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
 {{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
+-->
 <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
-= %set_build_flags for %build and %check =
+= %set_build_flags for %build, %check, and %install phases =
 <!-- The name of your change proposal -->
 == Summary ==
-Call %set_build_flags macro automatically at the beginning of the %build and %check phases of RPM builds in Fedora Linux.  This will ensure that the compiler flag environment variables are set for every RPM build.
+Call %set_build_flags macro automatically at the beginning of the %build, %check, and %install phases of RPM builds in Fedora Linux.  This will ensure that the compiler flag environment variables are set for every RPM build.
 <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
@@ Line 23: / Line 24: @@
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 -->
 == Current status ==
-[[Category:ChangePageIncomplete]]
+[[Category:ChangeAcceptedF36]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 44: / Line 44: @@
 ON_QA -> change is fully code complete
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OTEHEECFX2KOR2ILS6W35AYXONN5YWZP/ devel thread]
-* Tracker bug: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2728 #2728]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2040430 #2040430]
+* Release notes tracker: <will be not assigned by the Wrangler: not user-facing>
 == Detailed Description ==
@@ Line 61: / Line 62: @@
 * CXX
-These environment variables are set to the list of compiler flags defined in the system RPM configuration.  This macro is currently implicitly called when packages use some of the build system helper macros, like %configure, %cmake, and %meson.  However, not all packages use these macros and so some packages do not use the correct compiler flags as required by the Fedora packaging guidelines[1].
-This change will be implemented by updating the %__spec_build_pre and %__speck_check_pre macros in redhat-rpm-config to include %set_build_flags.  This will set these environment variables automatically before the %build and %check sections.  See the proposed implementation for more details.
+These environment variables are set to the compiler flags defined in the system RPM configuration.  This macro is currently implicitly called when packages use some of the build system helper macros, like %configure, %cmake, and %meson.  However, not all packages use these macros and so some packages do not use the correct compiler flags as required by the Fedora packaging guidelines[1].
-The purpose for making this change in both the %build and %check sections is because sometimes test code gets built in the %check sections for unit tests and this will ensure that the application code and its tests are built with the same set of flags.
+This change will be implemented by updating the %__spec_build_pre, %__speck_check_pre, and  __spec_install_pre macros in redhat-rpm-config to include %set_build_flags.  This will set these environment variables automatically before the %build, %check, and %install phases.  See the proposed [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/166 implementation] for more details.
+The purpose for making this change in the %check phase is because sometimes test code gets built in the %check phase for unit tests and this will ensure that the application code and its tests are built with the same set of flags.  This change is also being made in the %install phase for a similar reason, because sometime code gets built during the install phase.
+This change should have no impact on packages that already use %set_build_flags either directly or indirectly through another macro.  It also won't impact any package that currently sets these environment variables or modifies any of the %{build*_flags} macros in their %build or %check sections.
+Packagers may opt out of this behavior by doing:
+    %undefine _auto_set_build_flags
 [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
@@ Line 72: / Line 79: @@
 == Feedback ==
 <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
+Based on feedback on the devel list, the following changes were made:
+* Added %set_build_flags to the %install phase.
+* Added an opt-out mechanism:
+    %undefine _auto_set_build_flags
 == Benefit to Fedora ==
-This change will ensure that more packages are using the correct compiler flags, and bring them in compliance with the Fedora packaging guidelines.  It will also help improve the security of the distribution as many of the compiler flags help defend against common security attacks.
+This change will ensure that more packages are built using the correct compiler flags, and bring them in compliance with the Fedora packaging guidelines.  It will also help improve the security of the distribution as many of the compiler flags help defend against common security attacks.
 <!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
@@ Line 102: / Line 115: @@
       https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
       https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
+Examples:
+* ladspa
 -->
@@ Line 114: / Line 131: @@
 <!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
-* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Release engineering: [https://pagure.io/releng/issue/10482 #10482] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
 The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
@@ Line 134: / Line 151: @@
 == How To Test ==
-This change will be tested as part of the mass rebuild.
+This change will be tested by rebuilding packages as part of the mass rebuild.
 <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
@@ Line 148: / Line 165: @@
 . What are the expected results of those actions?
 -->
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == User Experience ==
+This change will make some packages less susceptible to security exploits.
 <!-- If this change proposal is noticeable by users, how will their experiences change as a result?
@@ Line 182: / Line 199: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+None needed.
 == Release Notes ==

Search

Changes/SetBuildFlagsBuildCheck: Difference between revisions