From Fedora Project Wiki
(Add myself to change)
No edit summary
 
(12 intermediate revisions by 3 users not shown)
Line 34: Line 34:
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ngompa|Neal Gompa]]
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain@fedoraproject.org, ngompa13@gmail.com
* Email: ignatenkobrain@fedoraproject.org, ngompa13@gmail.com
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/111 #111]
<!--- 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 54: 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 79: 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 98: 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 131: Line 132:
# Install package
# Install package
# Test that dependent applications work
# Test that dependent applications work
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== User Experience ==
== User Experience ==
Line 167: 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