From Fedora Project Wiki
(https://pagure.io/fesco/issue/1850)
No edit summary
Line 161: Line 161:
-->
-->


[[Category:ChangeReadyForFesco]]
[[Category:ChangeAcceptedF29]]
<!-- 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 -->

Revision as of 18:44, 4 March 2018


True Noarch Erlang Packages

Summary

Erlang packages are currently all installed into %{_libdir}/erlang/lib, despite most of them being noarch packages. This proposal is to modify Erlang to search %{_datadir}/erlang/lib in addition to %{_libdir}/erlang/lib when searching for dependencies.


Owner

  • Name: Randy Barlow
  • Email: bowlofeggs@fedoraproject.org
  • Release notes owner:
  • Responsible WG: erlang-sig


Current status

Detailed Description

The Erlang VM is currently hardcoded to search for dependencies in %{_libdir}/erlang/lib (on x86_64 this is /usr/lib64/erlang/lib). Due to this, all Erlang packages are currently compiled "archful", despite most of them being pure Erlang and thus truly noarch. This leads to longer build times for Erlang packages, and more storage used in Koji and on the mirrors.

This change proposes to add an additional path to be searched by the Erlang VM when finding dependencies at %{_datadir}/erlang/lib (on x86_64 this is /usr/share/erlang/lib). Additionally, the build macros will be udpated to automatically use this new path for installation for noarch packages. "Archful" packages will continue to store their files where they do today.

Benefit to Fedora

This will allow noarch Erlang packages to be built once rather than being built for each architecture, reduce build time, and will reduce the amount of storage used in Koji and on our mirrors.


Scope

  • Proposal owners:
    • Write a small patch for the Erlang VM to search two paths instead of one when loading dependencies.
    • Modify the Erlang RPM macros to use the new path for noarch packages.
  • Other developers:
    • Any developers who are not using the Erlang install RPM macro should modify their spec file to either use the macro, or to install their noarch packages to the new location.
  • Release engineering: #6685 (a check of an impact with Release Engineering is needed)
    • We could mass-rebuild Erlang packages, but everything should keep working without doing a mass rebuild so it is probably not necessary or worthwhile, unless we want to more immediately clear up a little disk space. The recommendation is to wait until the next mass rebuild since there will be no interruptions for existing packages, i.e., no effort required from Releng.
    • Any erlang packages that switch from being archful to being noarch will need all their dependent packages to be rebuilt, since they will no longer provide archful versions of themselves. However, this can be done at the time each package switches to being noarch. This change will not switch any particular packages to noarch.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

All Erlang packages should continue to work, even ones that are not rebuilt.


How To Test

Erlang packages that are installed to /usr/share/erlang/lib should continue to work. noarch packages built with the new RPM macros should install their content to /usr/share, and archful packages should continue to install to %{_libdir} as they do today.


User Experience

Users are not expected to notice this change, unless they are Erlang developers in which case they may notice that the noarch packages have moved to a new location.


Dependencies

This change does not depend on any other changes, or any other packages outside of the Erlang vm and the RPM macros. All packages that depend on Erlang and the RPM macros will continue to work correctly even if they are not updated to install to the new location, though it will be recommended that they update to use the new path once this effort is complete.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Revert the change to Erlang
  • Contingency deadline: F29 Beta Freeze
  • Blocks release? No
  • Blocks product? N/A

Documentation

No documentation outside of this proposal. Changes to the WIP packaging guidelines are part of the proposal, and will serve as documentation.


Release Notes