(Deferring to F36) |
|||
Line 182: | Line 182: | ||
ref: private-rawhide-autoconf-2.71 | ref: private-rawhide-autoconf-2.71 | ||
buildorder: 1` | buildorder: 1` | ||
After merging the changes needed for autoconf-2.71 and successfully building the package, scratch-builds for all dependent packages will be scheduled to verify everything works as expected. After the scratch-builds will be done, F36FTBFS tracking issues will be created in bugzilla for all packages, which have failed during the scratch-rebuild. There is no need to do a regular build for dependent packages, as we are testing only build-time functionality and run-time functionality of packages should not be changed with autoconf-2.71. Therefore there is no need to do a regular release bump and a build. | |||
== User Experience == | == User Experience == |
Latest revision as of 13:11, 26 August 2021
Autoconf-2.71
Summary
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.
Owner
- Name: Ondrej Dubaj
- Email: odubaj@redhat.com
Current status
- Targeted release: Fedora Linux 36
- Last updated: 2021-08-26
- FESCo issue: #2579
- Tracker bug: #1936597
- Release notes tracker: #661
Detailed Description
Upgrading autoconf from version 2.69 to version 2.71 according to new upstream release. Version 2.70 is skipped due to multiple ABI incompatibilities, where some of them were fixed in version 2.71. Years of development differ these two releases, so problems are expected.
This change might easily cause fails during builds of multiple packages, as some of them still require autoconf-2.69. This step must be properly discussed with maintainers of dependent packages, which should forward this change proposal to their upstream projects.
Feedback
Benefit to Fedora
Brings a stable and up-to-date version of autoconf according to upsteam release. It is expected, that in the future many upstream development teams will use autoconf-2.71 as their default builder, so Fedora will be prepared for such a step.
Scope
- Proposal owners:
- Prepare autoconf-2.71 as RPM package for Fedora Rawhide
- Prepare autoconf2.69-2.69 as RPM compat package for Fedora Rawhide
- Check software that requires
autoconf
orautoconf-2.69
and rebuild it with autoconf-2.71, if failed and autoconf-2.69 is required, compat package will be used - Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
- Rebuild depended packages with autoconf-2.71 in the side-tag
- Merge the side-tag to Rawhide
- Other developers:
- Check if their packages can be build with autoconf-2.71, if not, they are required to use autoconf2.69-2.69 compat package and also are required to make the appropriate changes to their packages.
- Release engineering: #Releng issue number
- Developers are advised to check their packages and build them in a prepared side-tag with autoconf-2.71, if failed, they are required to use compat package instead
- Policies and guidelines:
- No guidelines need to be updated according to this change.
- Trademark approval:
- Alignment with Objectives:
Upgrade/compatibility impact
Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern.
How To Test
Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).
The best way to rebuild new version of package against autoconf-2.71 is to create a pull-request against your dist-git repository (against rawhide branch). After that, you package will be automatically rebuild in the mentioned copr. Please find your package in the "Builds" tab and search in the various sub-tabs for your build.
If possible, please prepare a pull-request, so you can easily merge it, when the change will be executed.
For local testing and building, please download mock-config from the given copr repository and use it with your mock:
copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64 > odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg
mv odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg /etc/mock
Now we may run:
mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild <package-1.0-1.src.rpm>
Common failures and appropriate fixes available here: https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit?usp=sharing
Please do not hesitate to provide you own fix by using comment or proposing a suggestion to the document
If there is a need to test packages for other architectures than x86_64, we can use module chain-builds. Please use this option only in case you are not able to test the changes using mock or copr. Big thanks to Honza Horak for this idea and providing the yaml file.
All you need is to make appropriate changes, push them to private branch in fedora dist-git, modify the provided testmodule.yaml file and run fedpkg module-build --scratch --file testmodule.yaml --watch
. After this, please wait for the results. It may take a while, as building autoconf-2.71 can take up to 1 hour.
---
document: modulemd
version: 2
data:
name: testmodule
stream: 1.0
summary: Testing a thing
description: Just for a testing purposes
license:
module: [MIT]
dependencies:
- buildrequires:
platform: [f35]
requires:
platform: [f35]
components:
rpms:
autoconf:
rationale: autoconf-2.71
ref: private-rawhide-autoconf-2.71
buildorder: 0
unixODBC:
rationale: package to be tested
ref: private-rawhide-autoconf-2.71
buildorder: 1
After merging the changes needed for autoconf-2.71 and successfully building the package, scratch-builds for all dependent packages will be scheduled to verify everything works as expected. After the scratch-builds will be done, F36FTBFS tracking issues will be created in bugzilla for all packages, which have failed during the scratch-rebuild. There is no need to do a regular build for dependent packages, as we are testing only build-time functionality and run-time functionality of packages should not be changed with autoconf-2.71. Therefore there is no need to do a regular release bump and a build.
User Experience
Users will be able to use the newer version (2.71) of autoconf, and building packages with autoconf-2.69 won't be available, as it won't be present on the specific fedora version. This can affect 3rd partly packages, which are not part of Fedora.
Dependencies
Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for Fedora, what should be properly discussed and tested. List of dependent packages with their ability to be built with autoconf-2.71 can be found in the given copr project (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)
We should also look at dependent packages of libtool
and automake
(other critical autotools packages), as there might be some incompatibilities with the new autoconf version.
Contingency Plan
- Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide
- Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
- Blocks release? No
Documentation
Latest autoconf documentation: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html
Release Notes
Release notes for autoconf-2.70: https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html
Release notes for autoconf-2.71: https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html