Affects Version/s: None
Fix Version/s: None
The current Erlang/OTP installation process (using make release for instance) creates a few executable scripts (bin/erl, bin/start, bin/start_erl, erts-X.Y.Z/bin/erl, etc.) which define one or more absolute paths (BINDIR, ROOTDIR) that are freezing the installation into a specific directory.
This approach has the following consequences:
- it is not possible to freely move the installation directory later on, as the above scripts then point to incorrect paths
- it is needed to know upfront in which absolute path the Erlang runtime will be installed, or an extra step is required to update the scripts (using the ./Install script) to fix the paths and freeze the installation once the exact location is finally known
Looking at all the scripts, including the ./Install one, what seems to really matter is the directory structure relative to $ERL_ROOT in fact. I don't know the history/background for this choice to require an absolute path, it certainly brings some benefits (simplicity? robustness and wide-compatibility?) but it also adds an extra layer of complexity which creates some friction in a world of VMs / containers.
There are some ways to find the absolute path of a script from within itself, including following symlinks, such as this one:
Would a PR going in this direction be acceptable if removing the hardcoded absolute paths?
What would be other requirements to take into consideration (OS compatibility)? Other documented expectations that should be looked at carefully?
A smooth transition could be to keep full backwards compatibility with the current ./Install script approach by simply providing a default behavior when %FINAL_ROOTDIR% has not been set.