Latest revision as of 11:17, 10 February 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 35
Last updated: 2021-02-10
FESCo issue: <will be assigned by the Wrangler>
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

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
- Check software that requires autoconf or autoconf-2.69 and rebuild it with autoconf-2.71
- 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
Release engineering: #Releng issue number

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

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/).

Mass rebuild of dependent packages in a side tag.

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

@@ Line 1: / Line 1: @@
 <!-- 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 =
+= Autoconf-2.71 =
-Autoconf 2.69 -> 2.71 upgrade
 == 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?". -->
-Upgrading autoconf from version 2.69 to the last upstream version 2.71.
+Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.
 == Owner ==
@@ Line 13: / Line 12: @@
 This should link to your home wiki page so we know who you are.
 -->
-* Name: Ondrej Dubaj
+* Name: [[User:odubaj| Ondrej Dubaj]]
 <!-- 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: odubaj@redhat.com
@@ Line 19: / Line 18: @@
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 -->
 == Current status ==
@@ Line 32: / Line 30: @@
 <!-- [[Category:SystemWideChange]] -->
-* Targeted release: f35
+* Targeted release: [[Releases/35 | Fedora 35 ]]
 * 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 47: / Line 45: @@
 <!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 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 ==
@@ Line 80: / Line 80: @@
 -->
-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 we should be prepared for such a step.
+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:
 <!-- 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?-->
+**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
+**Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71
+**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: <!-- 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?-->
+**Check if their packages can be build with autoconf-2.71
 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- 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.
@@ Line 101: / Line 106: @@
 * Alignment with Objectives:
 <!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->
-Affects hundreds of packages.
 == Upgrade/compatibility impact ==
@@ Line 108: / Line 111: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Problems with building 3rd partly software might occur when upgrading to newer version of fedora, where autoconf-2.71 is present.
+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 ==
@@ Line 129: / Line 130: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Rebuilding your packages with autoconf-2.71 dependency. For testing, copr can be used https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
+Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).
+Mass rebuild of dependent packages in a side tag.
 == User Experience ==
 <!-- If this change proposal is noticeable by users, how will their experiences change as a result?
@@ Line 144: / Line 145: @@
 -->
-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.
+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 ==
@@ Line 150: / Line 151: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for fedora, what should be properly discussed and tested. Autoconf upgrade deadline depends on dependent packages, as if multiple packages are not able to be buit with autoconf-2.71, we cannot proceed with this upgrade. There are also problems with some upstream projects, which require autoconf-2.69 for their build. It is needed to discussed the possible upgrade olso on their side
+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 ==
 <!-- 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: moving this issue to f36, if not successfuly finished in f35  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide <!-- 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: f35 mass rebuild  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == Documentation ==
@@ Line 167: / Line 168: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+Latest autoconf documentation:
+https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html
 == Release Notes ==
@@ Line 175: / Line 178: @@
 Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
 -->
+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

Search

User:Odubaj: Difference between revisions