What was the intended use case for beam_lib:strip_release?

beam_lib:strip_release/1 removes all chunks except those needed by the loader from the BEAM files of a release.
In OTP 22.0 beam_lib:strip_release/2 was added to (according to the git commit message) allow extra chunks to be preserved for languages such as Elixir.

Since beam_lib:strip_release/1,2 is not used in OTP, i would like to know what the original/historical use case for this functionality was.

I can imagine it would be useful to reduce the size of the beam files on disk (and served over the network by a remote code server) after a release has been unpacked/installed by the release_handler.
Another use case i can come up with is: releases that will never be installed by the release_handler (e.g. the first release to be installed into a disk image).

The (longish) story behind this question:

At some point rebar3 enabled relx {mode, prod} for the rebar3 prod profile.
The {mode, prod} in relx does set {debug_info, strip} and in relx this means that beam_lib:strip_release is run.
The resulting release cannot be installed with release_handler:install_release/1 because the vsn information in the "Attr" chunk was removed from all beam files.

Unfortunately there is also this rebar3 issue: one can not override the relx {debug_info, strip} when in mode prod.

As a consequence: in order to get (production) releases that can be installed by release_handler with rebar3 tooling, one has to either: run a patched/old version of rebar3 or not use the rebar3 profiles prod/minimal and make up a new one.

5 Likes