Alternative to layout for classic confinement?

tsloughter · February 7, 2020, 6:38pm

In dev_mode I was using a layout so that erl could fine erlexec without modification:

erlef/erlang_snap/blob/master/snapcraft.yaml.tmpl#L53-L57


rebar3-libs:
  source: "https://github.com/erlang/rebar3/releases/download/${REBAR3_VERSION}/rebar3"
  # escripts are zip files of the libraries that make them up
  # this will result in a directory of all the rebar3 applications
  source-type: zip

Erlang is built and installed with --prefix=/usr which is why the layout creates a symlink for /usr/lib/erlang, it is where erl script will look for the erlexec binary.

After learning layout is not supported by classic confinement I’m wondering what is the best alternative for this snap to work?

alexmurray · February 9, 2020, 11:44pm

Can you just use --prefix=/snap/erlang/current/usr instead?

tsloughter · February 10, 2020, 3:32pm

Is that standard practice? I had thought that a bad solution since current is a symlink and could be pointed to a different install. But if running a non-current version is supposed to not work I suppose it would work. Is that the case?

lucyllewy · February 10, 2020, 4:00pm

Would setting ERL_LIBS make any difference? It looks like, from a very quick scan of the docs so I might be very wrong, this environment variable sets the library path. Try setting it to $SNAP/usr/lib?

tsloughter · February 10, 2020, 4:15pm

Na, ERL_LIBS is for discovering Erlang libraries that are only loaded after initial boot which requires finding erts.

You can see how the erl script is generated when compiling Erlang and how it references the install directory directly here:

lucyllewy · February 10, 2020, 4:29pm

You could manually patch that file before building with the following substitution:

sed -i 's|ROOTDIR="%FINAL_ROOTDIR%"|ROOTDIR="$SNAP/%FINAL_ROOTDIR%"|' erl.src.src

ijohnson · February 10, 2020, 4:30pm

The current symlink will always be there and point to a valid install when your snap is installed and enabled (except for bugs of course), so I would say try this and see what happens. It’s possibly you might run into issues down the road installing this snap on distros that don’t use /snap/... and instead have /var/lib/snapd/snap/... but I’m not sure.

tsloughter · February 12, 2020, 3:53pm

Ok. I had done that in my very first snap attempt and it worked for erl at least. I worried there might be other places that reference the install directly and then discovered layouts in the docs so moved on with that.

There must be other snaps that build projects don’t work if where they are told to install with --prefix is different from where they actually are on the filesystem? Is patching the strategy usually used? I couldn’t find anything in the docs for what I thought would be a common issue – well except for layouts docs

I’ll move forward with patching the erl script for now.

Thanks!

tsloughter · February 18, 2020, 3:54pm

So the use of patching the script to use $SNAP breaks when the snap is used to build other snaps.

I was creating an Elixir snap using the Erlang snap as a build-snap depedency which lead to:

Building elixir
/root/parts/elixir/install/usr/bin/erl: 29: exec: /snap/snapcraft/4007/usr/lib/erlang/erts-10.6.4/bin/erlexec: not found

Which makes sense, in the case of building a snap the $SNAP path is /snap/snapcraft/<revision>.

So I may have to switch to use /snap/erlang/current for now, until a better solution is known.

Is there at least a environment variable that is set for where snap directory is in case it isn’t in the root at /snap?

Also concerned about how this will work with parallel installs?

tsloughter · February 19, 2020, 12:23am

Oh wait, duh, if I’m going this direction I might as well just make the path by constructing it from the location of the script itself.

So I’m going to try to use the (path to the script)/../lib/erts-10.6.4/bin.