Bug 1309523

Summary: Bump up Erlang version
Product: [Fedora] Fedora EPEL Reporter: Gilles Dubreuil <gdubreui>
Component: erlangAssignee: Richard W.M. Jones <rjones>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: erlang, jeckersb, martin, plemenko, rjones, s, xavier
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-08 19:47:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1309525    

Description Gilles Dubreuil 2016-02-18 02:29:40 UTC
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 08:22:22 UTC
(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 05:49:19 UTC
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 14:46:32 UTC
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 14:06:58 UTC
(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.

Comment 5 Gilles Dubreuil 2020-04-08 19:47:12 UTC
Closing as this is outdated and newer version of Erlang are supported in more recent version of Fedora.