Latest revision as of 19:56, 17 July 2020

Use %make_build and %make_install macros

Summary

This change will increase the use of the %make_build and %make_install macros in spec files.

Owner

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

Current status

Targeted release: Fedora 33
Last updated: 2020-07-17
FESCo issue: #2420
Tracker bug: #1858398
Release notes tracker: #536

Detailed Description

The goal of this change is to standardize the usage of make in Fedora. All make invocations in spec files that use the %{_smp_mflags} macro will be modified to use the %make_build macro, and all make invocations that use the install target will be updated to use the %make_install macro. Any additional arguments to make that are not included in either the %make_build and %make_install will be preserved.

All changes will be submitted to dist-git repositories via pull requests. Pull requests will be merged after 1 week if there are no objections or earlier if approved by the package maintainers.

A script will be used to apply the necessary changes to the spec files, and the result will be manually inspected before being merged.

All packages updated by this change request will be rebuilt after the spec file changes are merged.

Some packages already use the %make_build and %make_install macros. These packages will be left unchanged.

Feedback

Feedback from thread on devel list:

There are concerns that replacing all make invocations with %make_build, even in cases where there may not be any benefit e.g. for make html may cause build failures or make the spec file less readable. An alternative to replacing all make invocations would be only to replace make in make $BUILD_TARGET, make check, and make install with %make_{build,install}.

As a result of this feedback, the change proposal has been updated to only update make %{_smp_mflags} ... and make install with the macros.

Benefit to Fedora

Standardized spec files.

This will make it easier to enforce consistent build flag usage across all of Fedora.

Scope

Proposal owners: Update spec files and submit pull requests and do new package builds. Optional: Merge pull requests (Proposal Owner would need to request to be added to provenpackagers group)

Other developers: Package owners may merge pull requests and submit new builds if they want, but this is not required for them. A member of the provenpackagers group will be needed to merge pull requests.

Release engineering: #9533 (a check of an impact with Release Engineering is needed)

Policies and guidelines: Package guidelines already specify that packages should use these macros when possible.

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

Upgrade/compatibility impact

No impact.

How To Test

Updated packages will be build tested using the koji-simple-ci test that is automatically run when a new pull request is created.

User Experience

End-users will not notice any changes.

Dependencies

No real dependencies, each package can be updated independently.

Contingency Plan

Contingency mechanism: None. If not all packages are updated in time, then the work can continue into the next release.
Contingency deadline: All work will be done in the rawhide branch, and will not be backported into the f33 branch once it is created, so whatever gets done before the branch date will make it into the release.
Blocks release? No
Blocks product? No

Documentation

There will be no documentation updates, since this change is bringing spec files up-to-date with the current packaging guidelines.

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.'''}}
 <!-- Self Contained or System Wide Change Proposal?
 Use this guide to determine to which category your proposed change belongs to.
@@ Line 21: / Line 19: @@
 <!-- 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 -->
-= Change Proposal Name <!-- The name of your change proposal --> =
+= Use %make_build and %make_install macros <!-- The name of your change proposal --> =
 == Summary ==
 <!-- 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?". -->
+This change will increase the use of the %make_build and %make_install macros in spec files.
 == Owner ==
@@ Line 32: / Line 32: @@
 This should link to your home wiki page so we know who you are.
 -->
-* Name: [[User:FASAcountName| Your Name]]
+* Name: [[User:tstellar| Tom Stellard]]
 <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
-* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
+* Email: <tstellar@redhat.com>
 <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
@@ Line 44: / Line 44: @@
 == Current status ==
-[[Category:ChangePageIncomplete]]
+[[Category:ChangeAcceptedF33]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 51: / Line 51: @@
 <!-- Select proper category, default is Self Contained Change -->
-[[Category:SelfContainedChange]]
+<!--[[Category:SelfContainedChange]] -->
-<!-- [[Category:SystemWideChange]] -->
+[[Category:SystemWideChange]]
-* Targeted release: [[Releases/<number> | Fedora <number> ]]
+* Targeted release: [[Releases/33 | Fedora 33 ]]
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 63: / Line 63: @@
 CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2420 #2420]
-* Tracker bug: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1858398 #1858398]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/536 #536]
 == Detailed Description ==
 <!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+The goal of this change is to standardize the usage of make in Fedora.  All make invocations in spec files that use the  %{_smp_mflags} macro will be modified to use the %make_build macro, and all make invocations that use the install target will be updated to use the %make_install macro.  Any additional arguments to make that are not included in either the %make_build and %make_install will be preserved.
+All changes will be submitted to dist-git repositories via pull requests.  Pull requests will be merged after 1 week if there are no objections or earlier if approved by the package maintainers.
+A script will be used to apply the necessary changes to the spec files, and the result will be manually inspected before being merged.
+All packages updated by this change request will be rebuilt after the spec file changes are merged.
+Some packages already use the %make_build and %make_install macros.  These packages will be left unchanged.
 == 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. -->
+Feedback from thread on devel list:
+* There are concerns that replacing all make invocations with %make_build, even in cases where there may not be any benefit e.g. for `make html` may cause build failures or make the spec file less readable.  An alternative to replacing all make invocations would be only to replace make in `make $BUILD_TARGET`, `make check`, and `make install` with %make_{build,install}.
+As a result of this feedback, the change proposal has been updated to only update `make %{_smp_mflags} ...` and `make install` with the macros.
 == Benefit to Fedora ==
@@ Line 104: / Line 120: @@
       https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
 -->
+* Standardized spec files.
+* This will make it easier to enforce consistent build flag usage across all of Fedora.
 == Scope ==
-* Proposal owners:
+* Proposal owners: Update spec files and submit pull requests and do new package builds.  Optional: Merge pull requests (Proposal Owner would need to request to be added to provenpackagers group)
 <!-- What work do the feature owners 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?-->
-* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Other developers: Package owners may merge pull requests and submit new builds if they want, but this is not required for them.  A member of the provenpackagers group will be needed to merge pull requests. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- 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] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Release engineering: [https://pagure.io/releng/issues/9533 #9533] (a check of an impact with Release Engineering is needed) <!-- 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 -->
-* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Policies and guidelines: Package guidelines already specify that packages should use these macros when possible.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
@@ Line 126: / Line 145: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+No impact.
 == How To Test ==
@@ Line 144: / Line 163: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+Updated packages will be build tested using the koji-simple-ci test that is automatically run when a new pull request is created.
 == User Experience ==
@@ Line 157: / Line 176: @@
   - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
 -->
+End-users will not notice any changes.
 == Dependencies ==
@@ Line 162: / Line 182: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+No real dependencies, each package can be updated independently.
 == Contingency Plan ==
 <!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency mechanism: None.  If not all packages are updated in time, then the work can continue into the next release.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: All work will be done in the rawhide branch, and will not be backported into the f33 branch once it is created, so whatever gets done before the branch date will make it into the release.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
-* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
+* Blocks product? No <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 == Documentation ==
@@ Line 178: / Line 198: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+There will be no documentation updates, since this change is bringing spec files up-to-date with the current packaging guidelines.
 == Release Notes ==

Search

Changes/UseMakeBuildInstallMacro: Difference between revisions