From Fedora Project Wiki
< Changes
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
- Proposal owners:
- We must rebuild Erlang R17 and submit it to build-overrides.
- We have to rebuild all the packages listed below in the Dependencies section.
- A necessary *.socket unit must be added to erlang-erts to enable EPMD socket activation.
- Every Erlang daemon must require epmd.socket.
- We need to fill new review request for erlang-ejournald
- We have to fill new review request for erlang-lager_journald_backend
- We have to patch out GUI parts and provide a way to tell user what to do in order to enable this functionality.
- Add another default directory to look for Erlang *.beam files.
- Every Erlang package must require erlang-rpm-macros.
- We must rebuild Erlang R17 and submit it to build-overrides.
- Other developers: N/A
- Release engineering: N/A
- Policies and guidelines:
- We have to create Erlang Packaging Guidelines which doesn't exist yet.
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)