Hi!
On Mon, Sep 30, 2019 at 10:02 PM Paul Gevers 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
