(Announcing the Change proposal) |
(Make it clear upfront that this is deferrred) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 25: | Line 25: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeAcceptedF35]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 35: | Line 35: | ||
[[Category:SystemWideChange]] | [[Category:SystemWideChange]] | ||
* Targeted release: [[Fedora | * (Originally) Targeted release: [[Fedora 35]] | ||
* Currently deferred | |||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * 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 | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
| Line 44: | Line 45: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* FESCo issue: | * FESCo issue: [https://pagure.io/fesco/issue/2541 #2541] | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1916921 #1916921] | ||
* Release notes tracker: <will be assigned by the Wrangler> | * Release notes tracker: <will NOT be assigned by the Wrangler, not user-facing> | ||
== Detailed Description == | == Detailed Description == | ||
| Line 107: | Line 108: | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/9934 #9934] (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. | <!-- 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 --> | 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 114: | Line 115: | ||
* Policies and guidelines: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Policies and guidelines: <!-- 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. --> | <!-- 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. --> | ||
The packaging guidelines will need to be updated to | The new macro will be a requirement for packages that install .o/.a files. So the packaging guidelines will need to be updated to clearly indicate that -static packages and more generally any package that installs a .o/.a file will need to use the new macro. | ||
* Trademark approval: N/A (not needed for this Change) | * Trademark approval: N/A (not needed for this Change) | ||
Latest revision as of 11:10, 6 November 2021
LTO Build Improvements
Summary
Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it.
Owner
- Name: Jeff Law
- Email: law@redhat.com
Current status
- (Originally) Targeted release: Fedora 35
- Currently deferred
- Last updated: 2021-11-06
- FESCo issue: #2541
- Tracker bug: #1916921
- Release notes tracker: <will NOT be assigned by the Wrangler, not user-facing>
Detailed Description
-ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error.
Feedback
Benefit to Fedora
The key benefit to Fedora is improved package build times and lower load on the builders.
Scope
- Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros.
- Other developers:
There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include:
- Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in.
- Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention.
- It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems.
I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues.
- Release engineering: #9934 (a check of an impact with Release Engineering is needed)
This should have no release engineering impacts.
- Policies and guidelines:
The new macro will be a requirement for packages that install .o/.a files. So the packaging guidelines will need to be updated to clearly indicate that -static packages and more generally any package that installs a .o/.a file will need to use the new macro.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
This proposal does not align with any current Fedora Objectives.
Upgrade/compatibility impact
This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts.
How To Test
No special testing is needed. Any issues with this proposal will show up as FTBFS issues.
User Experience
Users should see no changes to the user experience.
Dependencies
Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro.
Contingency Plan
If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35.
- Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed
- Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze.
- Blocks release? No
- Blocks product? No
Documentation
No upstream documentation. Packaging guidelines will need a minor update.
Release Notes
I do not expect this change to require any release notes.