Bug 1309523 - Bump up Erlang version
Bump up Erlang version
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: erlang (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1309525
  Show dependency treegraph
 
Reported: 2016-02-17 21:29 EST by Gilles Dubreuil
Modified: 2017-06-08 10:06 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gilles Dubreuil 2016-02-17 21:29:40 EST
Erlang RPM for EPEL7 is version 16
Meawhile Erlang 18 is available.
Fedora 23 is using version 17 while Fedora 24 (rawhide has version 18).  

Other projects like Elixir depends on more recent version of Erlang.
Comment 1 Peter Lemenkov 2016-02-18 03:22:22 EST
(In reply to Gilles Dubreuil from comment #0)
> Erlang RPM for EPEL7 is version 16
> Meawhile Erlang 18 is available.
> Fedora 23 is using version 17 while Fedora 24 (rawhide has version 18).  
> 
> Other projects like Elixir depends on more recent version of Erlang.

That's not simple. Erlang 18 has ABI-incompatibilities with Erlang R16 (NIF/Drivers API, obsolete functions like erlang:now(), different types like dict vs. dict:dicts, etc). I strongly support that but currently it would violate EPEL packaging rules too much.
Comment 2 Gilles Dubreuil 2016-02-19 00:49:19 EST
I agree this challenges Fedora/EPEL package updates policy.

One solution mentioned in related BZ#1309525 would be to have Red Hat Software Collections (SCL) to take care of it. Since Erlang is not part of SCL yet, it'd have to be added/accepted first.

Some thoughts here:
Programming languages have regular and important updates. EPEL, because of RHEL long life cycle cannot take advantage of those new releases.

Fedora has only the latest RPM available, which might make sense when targeting only cutting edge environments. But if EPEL could instead follow RHEL channels approach and keep all RPM released versions then that would not be an issue because those who need a previous version (Erlang 16, or Erlang 17) could still get it and the latest RPM version would be the latest but stable version (Erlang 18)
Comment 3 Martin Langhoff 2016-02-19 09:46:32 EST
Erlang 17 and Erlang 18 as currently packaged would conflict. We would need retool Erlang packaging to use 'alternatives', and alternatives isn't actually that good (i.e.: systems with two versions of Java have a hard time using both, if you need them for example to support different programs/daemons running at the same time).

These issues are exactly why SCL exists... IMO SCL is a saner path, but again quite a bit of work.

I am happy to lend a hand with an SCL Erlang 18 or a COPR repo. As I mentioned in  BZ#1309525 I have a very crude repo with Erlang 18 and Elixir 1.2.2 for EL7.
Comment 4 Xavier Bachelot 2017-06-08 10:06:58 EDT
(In reply to Peter Lemenkov from comment #1)
> (In reply to Gilles Dubreuil from comment #0)
> > Erlang RPM for EPEL7 is version 16
> > Meawhile Erlang 18 is available.
> > Fedora 23 is using version 17 while Fedora 24 (rawhide has version 18).  
> > 
> > Other projects like Elixir depends on more recent version of Erlang.
> 
> That's not simple. Erlang 18 has ABI-incompatibilities with Erlang R16
> (NIF/Drivers API, obsolete functions like erlang:now(), different types like
> dict vs. dict:dicts, etc). I strongly support that but currently it would
> violate EPEL packaging rules too much.

What about erlang 17 ? Does it have ABI incompatibilities too ?

Fwiw, I'm currently struggling with ejabberd for EL7. I have a working cluster, but I'm stuck with ejabberd 15.07 which is the latest version supporting erlang 16. erlang 17 would allow to get ejabberd 17.04 and probably future versions to run. I'd be willing to maintain ejabberd in EPEL 7, but I'd rather leave the erlang stack to more skilled buddies.

Note You need to log in before you can comment on or make changes to this bug.