From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
No edit summary
 
(15 intermediate revisions by 4 users not shown)
Line 32: Line 32:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:ignatenkobrain|Igor Gnatenko]]
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ngompa|Neal Gompa]]
<!-- 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: ignatenkobrain@fedoraproject.org, ngompa13@gmail.com
* Email: <your email address so we can contact you, invite you to meetings, etc.>
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/111 #111]
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 55: Line 54:
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
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1547061 #1547061]


== Detailed Description ==
== Detailed Description ==
Line 68: Line 67:


With this change, these scriptlets can be removed and ldconfig would be run just '''once''' per transaction.
With this change, these scriptlets can be removed and ldconfig would be run just '''once''' per transaction.
'''If your package places shared libraries in special locations referenced by ld.so.conf, you still need to run ldconfig manually.'''


For those who concerned about whether this is self-contained or system-wide change: there is no overhead if packagers don't remove ldconfig scriptlets in time, so completion doesn't depend whether packagers remove them or not. We are just making it possible.
For those who concerned about whether this is self-contained or system-wide change: there is no overhead if packagers don't remove ldconfig scriptlets in time, so completion doesn't depend whether packagers remove them or not. We are just making it possible.
Line 78: Line 79:


== Scope ==
== Scope ==
* Proposal owners: Make sure that DSO symlinks are being packaged<sup>[https://src.fedoraproject.org/rpms/redhat-rpm-config/c/12ace9bdb9bb61dbe1dbf4f250eee7c5913fb5c9 commit]</sup>, add transaction filetriggers to glibc<sup>[https://src.fedoraproject.org/rpms/glibc/c/1f24fb0da2ff5b11df79b885656a35df1a0ac8cc commit]</sup>.
* Proposal owners:
** Make sure that DSO symlinks are being packaged<sup>[https://src.fedoraproject.org/rpms/redhat-rpm-config/c/12ace9bdb9bb61dbe1dbf4f250eee7c5913fb5c9 commit]</sup>
** Add transaction filetriggers to glibc<sup>[https://src.fedoraproject.org/rpms/glibc/c/1f24fb0da2ff5b11df79b885656a35df1a0ac8cc commit] + [https://src.fedoraproject.org/rpms/glibc/c/6ff958f2aae58ce8d91999ba3b03e664b3c85e27 commit]</sup>
** Macroize ldconfig scriptlets<sup>[https://src.fedoraproject.org/rpms/redhat-rpm-config/c/1591a6fbf80efef362314652ad1e54bd41b0d52c f28] + [https://src.fedoraproject.org/rpms/redhat-rpm-config/c/6677def59b614f415cfc3a6f0884b14ba07938ce f27] + [https://src.fedoraproject.org/rpms/redhat-rpm-config/c/6d6dcc0612ecbf6e9b77845fb97ecaa8141bbd16 f26] + [https://src.fedoraproject.org/rpms/epel-rpm-macros/c/8c54d820ba193370a39e1547472163f1e0fd67ef epel7] + [https://src.fedoraproject.org/rpms/epel-rpm-macros/c/9cb54a8b9a971dd5c527bfa2f1d9a7701916558a el6]</sup>.
<!-- 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?-->
<!-- 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?-->


Line 84: Line 88:
<!-- 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?-->
<!-- 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] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/7284 #7284] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED 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 90: Line 94:
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: Packaging guidelines need to be updated to reflect  
* Policies and guidelines: Packaging guidelines need to be updated to reflect reality.
<!-- 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. -->


Line 97: Line 101:


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
RHEL6/RHEL7 (which is baked by EPEL in Fedora) at the point of writing this Change Proposal do not have mechanism of filetriggers, so packagers who want to support EPEL6/EPEL7 from same spec file would need to add special conditionals in their spec files.
Packagers who want to support only Fedora 28+ in their spec files can remove scriptlets entirely. For the rest, they should switch to use newly created macros.
 
Spec file should use <code>%ldconfig_post</code>, <code>%ldconfig_postun</code>, or preferably, <code>%ldconfig_scriptlets</code>.
 
* <code>%post -p /sbin/ldconfig</code> → <code>%ldconfig_post</code>
* <code>%postun -p /sbin/ldconfig</code> → <code>%ldconfig_postun</code>
* <code>%post -p /sbin/ldconfig</code> + <code>%postun -p /sbin/ldconfig</code> → <code>%ldconfig_scriptlets</code>
* Simple <code>/sbin/ldconfig</code> line in <code>%post/%postun</code> → <code>%?ldconfig</code>


<pre>
%if (0%{?rhel} && 0%{?rhel} <= 7) || (0%{?fedora} && 0%{?fedora} <= 27)
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%endif
</pre>
<!-- 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? -->
<!-- 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? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== How To Test ==
== How To Test ==
Line 124: Line 126:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
 
# Make sure you have latest glibc and redhat-rpm-config
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
# Find package which packages shared library
N/A (not a System Wide Change)
# Remove ldconfig scriptlets
# Build package
# Install package
# Test that dependent applications work


== User Experience ==
== User Experience ==
Line 160: Line 165:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF28]]
<!-- 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 -->

Latest revision as of 15:07, 2 March 2018


Removing ldconfig scriptlets

Summary

For many years, package maintainers were required to write scriptlets which call ldconfig in %post/%postun if they package shared libraries.

Owner

Current status

Detailed Description

Since time immemorial, Red Hat/Fedora packagers have been required to add a stanza to spec files for packages containing libraries to update the ldconfig cache.

%post -p /sbin/ldconfig    
%postun -p /sbin/ldconfig

To say this is annoying is to put it mildly. However, there was no standard mechanism to make this boilerplate go away. Now with RPM 4.13+, we should change this to file triggers and make all of that go away.

With this change, these scriptlets can be removed and ldconfig would be run just once per transaction.

If your package places shared libraries in special locations referenced by ld.so.conf, you still need to run ldconfig manually.

For those who concerned about whether this is self-contained or system-wide change: there is no overhead if packagers don't remove ldconfig scriptlets in time, so completion doesn't depend whether packagers remove them or not. We are just making it possible.

Benefit to Fedora

  • Packagers don't need to write ldconfig scriptlets anymore (often they forget to).
  • Significantly faster installation of packages.

Scope

  • Proposal owners:
  • Other developers: Package maintainers are advised to remove ldconfig scriptlets in order to achieve benefits specified above.
  • Release engineering: #7284 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: Packaging guidelines need to be updated to reflect reality.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Packagers who want to support only Fedora 28+ in their spec files can remove scriptlets entirely. For the rest, they should switch to use newly created macros.

Spec file should use %ldconfig_post, %ldconfig_postun, or preferably, %ldconfig_scriptlets.

  • %post -p /sbin/ldconfig%ldconfig_post
  • %postun -p /sbin/ldconfig%ldconfig_postun
  • %post -p /sbin/ldconfig + %postun -p /sbin/ldconfig%ldconfig_scriptlets
  • Simple /sbin/ldconfig line in %post/%postun%?ldconfig


How To Test

  1. Make sure you have latest glibc and redhat-rpm-config
  2. Find package which packages shared library
  3. Remove ldconfig scriptlets
  4. Build package
  5. Install package
  6. Test that dependent applications work

User Experience

Installation of packages is significantly faster.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes