snapcraft.yaml: update PATH so that snapcraftctl is found #111
Conversation
mvo5
force-pushed
the
unbreak-travis
branch
2 times, most recently
from
32e6533
to
33569d7
Compare
With snapcraft 3.0 the snapcraftctl binary is no longer an alias
but a binary that is installed into
/snap/snapcraftctl/$rev/bin/scriptlet-bin
This PR ensures this is reflected in the override-{stage,prime}
scriptlets. This will unbreak the travis builds.
mvo5
changed the title
mvo5
changed the title
| export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" | ||
| # ensure snapcraftctl is found, see | ||
| # https://github.com/snapcore/snapcraft/pull/2251 | ||
| export PATH="$PATH:/snap/snapcraft/current/bin/scriptlet-bin" |
There was a problem hiding this comment.
The path belongs to a private binary from snapcraft, is this really what we want to do?
There was a problem hiding this comment.
I can expand the command a bit maybe - so what happens is that snapcraft 3.0 will run the scriptlets in a subshell with custom PATH and LD_LIBRARY_PATH. Unfortunately this breaks on non-18.04 systems because of incompatible binaries. Hence the workaround to rewrite PATH was added. However in snapcraft 3.0 snapcraftctl is put into a custom PATH (it used to be a shell alias). This is why this is needed, does that answer the question?
There was a problem hiding this comment.
This change does indeed seem a bit strange, but it makes sense in our case.
@zyga this is a private path but what mvo proposes here is anyway what snapcraft does by default anyway (I guess from the PR attached in the comment). Just in this case we need to do it ourselves as we have to tinker with the PATH manually.
With snapcraft 3.0 the snapcraftctl binary is no longer an alias
but a binary that is installed into
This PR ensures this is reflected in the override-{stage,prime}
scriptlets. This will unbreak the travis builds.