From Fedora Project Wiki
 
(58 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Perl: Replace MODULE_COMPAT by macro =
= Perl: Replace versioned MODULE_COMPAT_ requires by RPM dependency generator =


== Summary ==
== 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`.
 
A ''perl(:MODULE_COMPAT_%(eval "<nowiki>`%{__perl} -V:version`</nowiki>"; echo $version))'' run-time dependency will be removed from all Perl spec files. The replacement will be generated by dependency generator which will be placed in ''perl-generators''.
 
The result of generator will be based on content of the binary packages. That will significantly shrink an amount of Perl packages required to be rebuilt with each Perl upgrade.


== Owner ==
== Owner ==
Line 12: Line 15:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF38]]
 
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]


Line 24: Line 26:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QIICSZFRILYI77JBBJ4YU3I54VE6V4YK/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2898 #2898]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2158233 #2158233]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/943 #943]


=== Completed items ===
=== Completed items ===
* Add the file `/usr/lib/rpm/fileattrs/perlcompat.attr` to ''perl-generators'' in F38
* Add the file `/usr/lib/rpm/fileattrs/perlcompat.attr` to ''perl-generators'' in F37
* Add the file `/usr/lib/rpm/fileattrs/perlcompat.attr` to ''perl-generators'' in F36
* Update [https://pagure.io/packaging-committee/issue/1243 Fedora Packaging Guidelines for Perl]
* Remove ''perl(:MODULE_COMPAT_XXX)'' from run-time in all F38 spec files (3259)
* Create the package [https://bugzilla.redhat.com/show_bug.cgi?id=2159396 ''perl-generators-epel''] which provides the functionality for EPEL 7/8/9
* Add ''perl-generators-epel'' to ''epel-rpm-macros'' ([https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61 EPEL7], [https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60 EPEL8], [https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59 EPEL9])


=== Items in progress ===
=== Items in progress ===
* Add `%perl_require_compat` macro to perl-srpm-macros in F38
* [https://pagure.io/FedoraReview/pull-request/472 Update ''fedora-review''] to not check ''perl(MODULE_COMPAT_XXX)'' in spec files ([https://bugzilla.redhat.com/show_bug.cgi?id=2161280 BZ#2161280])
* 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 [[Packaging:Perl | Fedora Packaging Guidelines for Perl]]
* Replace `perl(:MODULE_COMPAT_XXX)` to `%perl_require_compat` run-time dependency in all F38 spec files (3335)


== Detailed Description ==
== Detailed Description ==


The macro `%perl_require_compat` will be defined in the rpm `perl-srpm-macros`.
The list of packages that need to be rebuilt with the new major version of Perl is determined according to the dependency on ''perl(:MODULE_COMPAT_XXX)'' now.  


`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" : "%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}" ]`
In Fedora, all Perl modules run-require the versioned ''perl(:MODULE_COMPAT_XXX)'' provided by ''perl-libs'' now.


== Feedback ==
However, only packages with compiled code 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. For those packages, we need to ensure that the packages will use the right version of ''libperl.so'' for the Perl used during the rebuild.
<!-- 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. -->
 
The other packages don't need to be rebuilt against each new major version of Perl, they only have to require non-versioned ''perl-libs'' which includes all directories used by all Perl modules.
 
The new generator will generate runtime requirements based on files which are in the package.
 
The content of ''/usr/lib/rpm/fileattrs/perlcompat.attr'' will be:
%__perlcompat_requires() %{lua:
    if macros[1]:match('.+%.so$') and macros.perl_version then
      print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
    else
      print('perl-libs')
    end
}
%__perlcompat_path ^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
 
The file will be placed in ''perl-generators'' which requires ''perl-macros''. Since RPM 4.15, ''perl-macros'' provides definition of ''perl_vendor*'', ''perl_privlib'' and ''perl_archlib'' and it requires  ''perl-interpreter''. The Fedora guidelines already require Perl modules to BuildRequire ''perl-generators''.
 
The generator will evaluate to the correct value. There is a known, yet harmless, imperfection: The generator will evaluate to ''perl-libs'' for each package which contains any (non *.so) file in the given paths. It means the packages with compiled code will usually require both ''perl(:MODULE_COMPAT_<perl_version>)'' and ''perl-libs''.
 
This generator will work for all supported Fedoras.
 
I'll add [https://jplesnik.fedorapeople.org/perl-generators-epel/ ''perl-generators-epel''] which provides the similar behavior for EPEL 7/8/9.


== Benefit to Fedora ==
== 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.
It will simplify the rebuild and reduce the number of packages which have to be rebuild from 3259 to approximately 600. 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. The generator approach will also be shorter and clearer for packagers.


== Scope ==
== Scope ==
* Proposal owners:
* 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-generators'' source package.
** Add ''/usr/lib/rpm/fileattrs/perlcompat.attr'' to ''perl-generators'' package in older Fedoras.
** Remove Requires ''perl(:MODULE_COMPAT_XXX)'' 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 -->
* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 66: Line 92:


* Trademark approval: N/A (not needed for this Change)
* 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:  
* 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 ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
N/A
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
A good "how to test" should answer these four questions:
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


All packages with compiled code should run-require ''perl(:MODULE_COMPAT_%{perl_version})'' and probably also ''perl-libs'' - it is explaned in '''Detailed Description'''. The other packages should run-require ''perl-libs'' only.


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?
There should not be any remarkable change in user experience.
 
This section partially overlaps with the Benefit to Fedora section above. This section should be primarily about the User Experience, written in a way that does not assume deep technical knowledge. More detailed technical description should be left for the Benefit to Fedora section.
 
Describe what Users will see or notice, for example:
  - Packages are compressed more efficiently, making downloads and upgrades faster by 10%.
  - Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day.
- Libreoffice is one of the most commonly installed applications on Fedora and it is now available by default to help users "hit the ground running".
- 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.
-->


== Dependencies ==
== 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 3259 source packages and all binary noarch packages. 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 ==
== 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: Before Mass Rebuild.
<!-- 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 ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Release Notes ==
== 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.
-->

Latest revision as of 06:41, 1 February 2023

Perl: Replace versioned MODULE_COMPAT_ requires by RPM dependency generator

Summary

A perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) run-time dependency will be removed from all Perl spec files. The replacement will be generated by dependency generator which will be placed in perl-generators.

The result of generator will be based on content of the binary packages. That will significantly shrink an amount of Perl packages required to be rebuilt with each Perl upgrade.

Owner

Current status

Completed items

  • Add the file /usr/lib/rpm/fileattrs/perlcompat.attr to perl-generators in F38
  • Add the file /usr/lib/rpm/fileattrs/perlcompat.attr to perl-generators in F37
  • Add the file /usr/lib/rpm/fileattrs/perlcompat.attr to perl-generators in F36
  • Update Fedora Packaging Guidelines for Perl
  • Remove perl(:MODULE_COMPAT_XXX) from run-time in all F38 spec files (3259)
  • Create the package perl-generators-epel which provides the functionality for EPEL 7/8/9
  • Add perl-generators-epel to epel-rpm-macros (EPEL7, EPEL8, EPEL9)

Items in progress

Detailed Description

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

In Fedora, all Perl modules run-require the versioned perl(:MODULE_COMPAT_XXX) provided by perl-libs now.

However, only packages with compiled code 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. For those packages, we need to ensure that the packages will use the right version of libperl.so for the Perl used during the rebuild.

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

The new generator will generate runtime requirements based on files which are in the package.

The content of /usr/lib/rpm/fileattrs/perlcompat.attr will be:

%__perlcompat_requires() %{lua:
   if macros[1]:match('.+%.so$') and macros.perl_version then
      print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
   else
      print('perl-libs')
   end
}
%__perlcompat_path ^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+

The file will be placed in perl-generators which requires perl-macros. Since RPM 4.15, perl-macros provides definition of perl_vendor*, perl_privlib and perl_archlib and it requires perl-interpreter. The Fedora guidelines already require Perl modules to BuildRequire perl-generators.

The generator will evaluate to the correct value. There is a known, yet harmless, imperfection: The generator will evaluate to perl-libs for each package which contains any (non *.so) file in the given paths. It means the packages with compiled code will usually require both perl(:MODULE_COMPAT_<perl_version>) and perl-libs.

This generator will work for all supported Fedoras.

I'll add perl-generators-epel which provides the similar behavior for EPEL 7/8/9.

Benefit to Fedora

It will simplify the rebuild and reduce the number of packages which have to be rebuild from 3259 to approximately 600. 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. The generator approach will also be shorter and clearer for packagers.

Scope

  • Proposal owners:
    • Submit Fedora Packaging Guidelines for Perl update to Fedora Packaging Committee.
    • Update and rebuild perl-generators source package.
    • Add /usr/lib/rpm/fileattrs/perlcompat.attr to perl-generators package in older Fedoras.
    • Remove Requires perl(:MODULE_COMPAT_XXX) in all spec files.
  • Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.
  • 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

N/A

How To Test

All packages with compiled code should run-require perl(:MODULE_COMPAT_%{perl_version}) and probably also perl-libs - it is explaned in Detailed Description. The other packages should run-require perl-libs only.

User Experience

There should not be any remarkable change in user experience.

Dependencies

This change will affect 3259 source packages and all binary noarch packages. 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: Before Mass Rebuild.
  • Blocks release? No.

Documentation

Release Notes