You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I stage the bash and quilt packages in a part in a classic snap, then the snap gets built with a bin/bash file that is not executable. Subsequent attempts to use it fail.
Expected result: parts/demo/install/bin/bash is executable, and this passes through to the final snap (if you continue you should also see it in prime/bin/bash as executable, etc).
Actual result: parts/demo/install/bin/bash is not executable and this passes through to the final snap. Then scripts that try to use it fail.
The trace output suggests that snapcraft is doing something because usr/share/quilt/compat/bash is a symlink. If I drop quilt from stage-packages, then bin/bash isn't created.
I found this when trying to move the git-ubuntu snap to core24. That's complex enough so I came up with a minimal reproducer.
Please note that since you're building a classic snap, the symlink in usr/share/quilt/compat/bash may be incorrect. Do you expect this to go to the system's bash, or the bash staged inside this snap? If the latter, you'll need to rewrite that symlink (probably in an override-build script) to point to ../../../bin/bash rather than /bin/bash - otherwise it'll execute the system's bash.
@mr-cal@cmatsuoka Should craft-parts be rewriting absolute symlinks like this when staging a package?
Do you expect this to go to the system's bash, or the bash staged inside this snap?
In quilt's case, I'd like for it to be entirely contained within the classic snap, and not touch the host system except to act on the source tree and patch series that it is given that will be on the host system. That suggests that the symlinks should be relative.
Of course it's tricky in the case of a classic snap where these sorts of things tend to be leaky. I'm not sure the symlinks are actually used. If they are, then that's probably wrong and I can close that leak, but there are probably others. I try to ensure that there's good test coverage (I know quilt is exercised), and then act when I have specific test failures. But sure, I can tweak this in override-build to make them relative if snapcraft can't do that for me in any other more abstract way.
The reason I ran into this was because in some other places I was using $SNAP/bin/bash and because I happened to stage-packages: [quilt], switching from core20 to core24 regressed that location. I know behaviour has changed since usrmerge. I've tried to eliminate use of that path now, favouring $SNAP/usr/bin/bash instead for unrelated reasons.
Bug Description
If I stage the
bash
andquilt
packages in a part in a classic snap, then the snap gets built with abin/bash
file that is not executable. Subsequent attempts to use it fail.To Reproduce
On a fresh Noble VM:
Expected result:
parts/demo/install/bin/bash
is executable, and this passes through to the final snap (if you continue you should also see it inprime/bin/bash
as executable, etc).Actual result:
parts/demo/install/bin/bash
is not executable and this passes through to the final snap. Then scripts that try to use it fail.Environment
Ubuntu 24.04 cloud image, snapcraft in destructive mode. Snapcraft snap 8.4.3 (12823).
snapcraft.yaml
Relevant log output
Additional context
The trace output suggests that snapcraft is doing something because
usr/share/quilt/compat/bash
is a symlink. If I dropquilt
fromstage-packages
, thenbin/bash
isn't created.I found this when trying to move the git-ubuntu snap to core24. That's complex enough so I came up with a minimal reproducer.
Workaround: I did this:
The text was updated successfully, but these errors were encountered: