Hi! On Mon, Sep 30, 2019 at 10:02 PM Paul Gevers <elb...@debian.org> wrote: > > > > Apparently, elixir-land needs to be rebuilt against newer erlang 22.1. > > That's not the proper way to solve bugs.
Indeed, it seems to me now that it's a bug in packaging Erlang and Elixir. We'll try to fix it. > > > Currently, it doesn't pass autopkgtest (see [1] for details). > > > > There were some internal changes in Erlang re module (regular expressions) > > which > > triggered the test failure. After a simple rebuild all tests pass again. > > This means that either erlang changed something they shouldn't have > changed (think of software outside of the Debian archive here as well), > or elixir-lang is buggy and it is using something of erlang that it > should be using (in its autopkgtest). Please discuss and figure out > which package needs to fix something and reassign the package to it. After some digging, I've found that the situation is indeed documented. Citing from elixir-lang-source/lib/elixir/lib/regex.ex: Regular expressions built with sigil are precompiled and stored in `.beam` files. Precompiled regexes will be checked in runtime and may work slower between operating systems and OTP releases. This is rarely a problem, as most Elixir code shared during development is compiled on the target (such as dependencies, archives, and escripts) and, when running in production, the code must either be compiled on the target (via `mix compile` or similar) or released on the host (via `mix releases` or similar) with a matching OTP, OS and architecture as as the target. If you know you are running on a different system that the current one and you are doing multiple matches with the regex, you can manually invoke `Regex.recompile/1` or `Regex.recompile!/1` to perform a runtime version check and recompile the regex if necessary. It happened that the PCRE library Erlang uses was updated in Erlang 22.1, so the precompiled regexs (at least some of them) stopped working in the new runtime. The elixir sources have to be rebuilt to match the PCRE changes (there's no need to fix anything in the sources because re: API in Erlang didn't change). Can it be treated as a bug in Elixir that needs to be fixed? I'm not sure upstream will agree. So, I'd like to suggest the following: I'll add another virtual package (erlang-pcre-8.43 as for now) reflecting the PCRE version currently in Erlang. Elixir will depend on it (via ${erlang-pcre:Depends} substitution variable and the erlang-depends script call in debian/rules). This means that when the PCRE library updates, elixir temporarily becomes uninstallable and needs a rebuild (binNMU will suffice in this case). The PCRE library updates in Erlang infrequently (approximately one time per year), so I don't think that it'd be a serious burden to the maintainers. Alternatively, one could try to convince Elixir authors not to precompile regex on creation (or to patch it). Cheers! -- Sergei Golovan