Revision as of 11:56, 8 November 2022

Perl: Replace MODULE_COMPAT by macro

Summary

The versioned perl(:MODULE_COMPAT_XXX) (provided by perl-libs) will be required only by multi-arch packages. For those packages, we need to ensure that the packages will use the right libperl.so for the Perl used during the rebuild.

The noarch packages will depend on non-version perl-libs.

The macro %perl_require_compat will evaluate the requires based on %{_target_cpu}. The macro will be defined in the rpm perl-srpm-macros.

%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" : "%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}" ]

Owner

Name: Jitka Plesnikova
Email: <jplesnik@redhat.com>

Current status

Targeted release: Fedora Linux 38
Last updated: 2022-11-08
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>

Completed items

Items in progress

Add %perl_require_compat macro to perl-srpm-macros in F38
Add %perl_require_compat macro to perl-srpm-macros in F37
Add %perl_require_compat macro to perl-srpm-macros in F36
Add %perl_require_compat macro to perl-srpm-macros in F35
Update Fedora Packaging Guidelines for Perl
Replace perl(:MODULE_COMPAT_XXX) by %perl_require_compat dependency in all F38 spec files (3335)
- Have to update all kinds of dependencies: Requires, Recommends, Suggests

Detailed Description

The list of packages that need to be rebuilt with the new Perl is determined according to the dependency on perl(:MODULE_COMPAT_XXX) now.

However, only multi-arch packages need to have a dependency on the particular version of Perl it was built against, or on a newer version of Perl that provides backward compatibility with it.

The noarch packages don't need to be rebuild against each new major version of Perl, they only need to require perl-libs which includes all directories used by all Perl modules.

The macro %perl_requires_compat will be evaluated to the correct value.

Feedback

Benefit to Fedora

It will simplify the rebuild and reduce the number of packages which have to be rebuild. It should currently be enough to rebuild only multi-arch packages and those that are part of the Perl itself (dual-life packages). Here we need to ensure that the packages will use the right libperl.so for the Perl used.

Scope

Proposal owners:
- Submit Fedora Packaging Guidelines for Perl update to Fedora Packaging Committee.
- Update and rebuild perl-srpm-macros source package.
- Add %perl_require_compat to perl-srpm-macros package in older Fedoras.
- Replace Requires for perl(:MODULE_COMPAT_XXX) with %perl_require_compat in all spec files.

Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.

Release engineering: No action needed. #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

How To Test

User Experience

Dependencies

This change will affect 3305 source packages and 2500 binary packages. Their spec files will be updated. The rebuild of affected packages will be done by mass rebuild of Fedora 38 . There is no dependency on other Fedora changes

Contingency Plan

Contingency mechanism: The change will be reverted.
Contingency deadline: Any time.
Blocks release? No.

Documentation

N/A (not a System Wide Change)

Release Notes

@@ Line 2: / Line 2: @@
 == Summary ==
-The versioned `perl(:MODULE_COMPAT_XXX)` (provided by `perl-libs`) will be required only by multi-arch packages. For those packages, we need to ensure that the packages will use the right libperl.so for the Perl used. The `noarch` packages will depend  on non-version `perl-libs`.
+The versioned `perl(:MODULE_COMPAT_XXX)` (provided by `perl-libs`) will be required only by multi-arch packages. For those packages, we need to ensure that the packages will use the right `libperl.so` for the Perl used during the rebuild.
-The macro `%perl_require_compat` will evaluate the requires based on `%{_target_cpu}`. It will be defined in the rpm `perl-srpm-macros`.
+The `noarch` packages will depend on non-version `perl-libs`.
+The macro `%perl_require_compat` will evaluate the requires based on `%{_target_cpu}`. The macro will be defined in the rpm `perl-srpm-macros`.
 `%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" : "%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}" ]`
@@ Line 63: / Line 65: @@
 == 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?-->
+** Submit Fedora Packaging Guidelines for Perl update to Fedora Packaging Committee.
+** Update and rebuild perl-srpm-macros source package.
+** Add ''%perl_require_compat'' to ''perl-srpm-macros'' package in older Fedoras.
+** Replace Requires for ''perl(:MODULE_COMPAT_XXX)'' with ''%perl_require_compat'' in all spec files.
-* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.
-<!-- 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: No action needed. [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.
-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 needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 76: / Line 78: @@
 * Trademark approval: N/A (not needed for this Change)
-<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
 * 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 -->
 == Upgrade/compatibility impact ==
@@ Line 119: / Line 119: @@
 == Dependencies ==
 <!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
+This change will affect 3305 source packages and 2500 binary packages. Their spec files will be updated. The rebuild of affected packages will be done by mass rebuild of Fedora 38 . There is no dependency on other Fedora changes
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == 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: The change will be reverted.
-* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: Any time.
-<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
+* Blocks release? No.
-* Contingency deadline: N/A (not a System Wide Change)  <!-- 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 -->
 == Documentation ==
@@ Line 140: / Line 136: @@
 == Release Notes ==
-<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
-<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
-Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.
--->

Search

Changes/Perl replace MODULE COMPAT by generator: Difference between revisions