Elixir_1.12.0,_OTP_24.0,_port_updates_&_older_OTP_version_depr ecations

hi folks

```
$ uname -a
FreeBSD wintermute 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

$ iex
Erlang/OTP 24 [erts-12.0.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace] [sharing-preserving]

Interactive Elixir (1.12.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> IO.puts("woot")
woot
```

You can grab the patches off phab, or from https://git.sr.ht/~dch/ports/log/beam

I would like to make 3 updates & 2 proposals:


1. add a lang/elixir-devel version.

        Revision URI: https://reviews.freebsd.org/D30490

This would allow users to always have the latest elixir release installed.
NB many elixir libraries today don't handle all the deprecations in 1.12/OTP24.

This is currently bound to latest lang/erlang version (24) during compilation
but doesn't have to be. In most cases, dependent ports (like elixir-hex etc)
would not require this as a direct dependency.

My perception is that most users install packages via mix, and not via
FreeBSD ports, so this shouldn't break anybody's setup if they install
the -devel version (which could force pkg to uninstall any lang/elixir
dependencies).

2. bump lang/elixir to 1.11.x branch.

https://reviews.freebsd.org/D28092 already does this, but...

this requires "making rabbitmq work" which Jimmy seems to know what's
needed.

If this already works with 1.12.0 then we could roll with that, but I
expect there would be a reasonable amount of dependent ports that break.

Any of the ~ 75 elixir related ports that don't build with 1.11.x should
be considered deprecated if there's not a newer upstream release.



3. add OTP 24.0

        Revision URI: https://reviews.freebsd.org/D30494

JIT!!! nuff said!!

4. proposal to drop most of the elixir-* dependent ports

I'm not convinced most of these ports are actually worth having in
ports at all, who would install any of these, and not use mix & hex
packages directly?

This would be in line with e.g. golang dependencies. Unless there is
some particularly useful NIF/C dependencies we should consider dropping
them.



5. proposal to drop OTP20 & erlang-riak

Both are long out of upstream support releases

The former has 0 dependent ports, so this shouldn't break the world.
The latter doesn't work at all on 12.x + nor with modern LLVM.

A+
Dave
—
O for a muse of fire, that would ascend the brightest heaven of invention!