π Better Erlang Integration
π Summary
Improve Erlang software integration with the rest of Fedora.
π Owner
- Name: Peter Lemenkov, Fedora Erlang SIG
- Email: lemenkov@gmail.com, erlang@lists.fedoraproject.org
- Release notes owner:
π Current status
- Targeted release: Fedora 21
- Last updated: 2014-03-23
- Tracker bug: <will be assigned by the Wrangler>
π Detailed Description
Erlang in Fedora is already in a good shape. However we can do better since there are a number of annoying shortcomings and issues. Just a few of them:
- Fedora partially enabled Ellyptic Curve Crypto recently but we still provide Erlang with EC disabled completely because there is no way to enable just a few EC in the current Erlang version.
- Erlang<->systemd interaction is in a quite poor state currently.
- There is no way to install "headless" Erlang. Every Fedora Erlang user have to install graphical libraries even if (s)he doesn't want to use GUI on the target machine.
- Every daemon written in Erlang has its own logging solution which doesn't use neither syslog nor Journald.
- Erlang packaging is quite complex and undocumented mostly.
In order to address all these issues we should do the following:
- Enable fine grained EC crypto support by upgrading Erlang to the latest R17.
- Start working on a better systemd support in Erlang by enabling EPMD systemd support. This could be done by merging patches from Matwey V. Kornilov.
- Add erlang-ejournald, erlang-lager_journald_backend, and make Journald as a default logging backend.
- Split-off infrequently used modules which requires X11, Pulseaudio and ensure that it won't break anything.
- Fix the long-standing noarch issue by providing additional default location for Erlang bytecode data.
- Update Erlang RPM-related macros to improve packaging by reducing spec-file sizes.
π Benefit to Fedora
- Users will get initial EC support in Erlang. We still can't enable EC fully but at least we will enable some EC curves.
- Users will have less issues caused by poor systemd and EPMD integration (lost node names during other Erlang daemons restarts etc).
- Users will get centralized unified logging from all Erlang applications
- Users won't have to install X11-related libraries if they don't want to.
- Packagers won't see scary rpmlint messages regarding marking arch-independent package as arch-dependent one.
- Packagers will spend less time on packaging Erlang software for Fedora.
π Scope
We have to rebuild all the packages listed below in the Dependencies section.
- Proposal owners:
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
π Upgrade/compatibility impact
Every Erlang upgrade requires the rebuilding of modules which contains ports or NIFs, and we will rebuild all such modules in Fedora. However if a user has some additional modules not available in a Fedora repository,then (s)he will have to rebuild it manually.
π How To Test
- Ensure that high-grade Erlang applications are still working:
Name | Tested |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
- Collect feedback from volunteers regarding their experience with this Erlang/OTP version
π User Experience
Fedora Erlang users will get more robust Erlang configurations. Less issues, more detailed logs.
π Dependencies
The following packages must be rebuilt:
Name | Rebuilt |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
|
No |
π 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 <-- Applicable for Changes that blocks specific product release/Fedora.next -->
π Documentation
N/A (not a System Wide Change)