Stage-packages not running post installation script?

snapcraft
1

My snap uses the libblas package. If we look at this package, we find it contains this shared object. Note the /blas/ subdir.

/usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0

Now the package contains a postinst script calling update-alternatives to make it all work (as below). It does seem that listing libblas3 in stage-packages does not cause update-alternatives to be executed and thus my snap can’t find libblas.so :frowning:

update-alternatives --install /usr/lib/x86_64-linux-gnu/libblas.so.3 \
                    libblas.so.3-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 10

Is this on purpose? If so, how to get the desired result in a clean way? I guess I can override (stage?) to make the symlink, but that seems rather ugly.

Snapcraft 7.2.7 using core22.

2

I’m unsure for the actual update-alternatives part of things, but you have two rather clean choices available

  1. Add $SNAP/usr/lib/x86_64-linux-gnu/blas/ to $LD_LIBRARY_PATH, such as via
environment:
  LD_LIBRARY_PATH: $SNAP/usr/lib/x86_64-linux-gnu/blas

(at the top level of the YAML)

Don’t use e.g LD_LIBRARY_PATH: $LD_LIBRARY_PATH:..., it isn’t necessary and actually causes issues.

  1. You can make use of organize to move the files so they’re in the search targets for the default $LD_LIBRARY_PATH, e.g, by adding this to the relevant part containing the stage-packages for BLAS
organize:
      usr/lib/*-linux-gnu/blas/*: usr/lib/

This is effectively the same as symlinking it, except fits into the YAML structure a bit better than e.g override-prime and symlinks or equivilents would.

Personally, I prefer the second approach as it meant I didn’t have to worry about using a different $LD_PRELOAD_PATH for every CPU architecture you might end up supporting.

3

Stage packages are simply unpacked in the part’s install directory (not directly in the stage directory as one could imagine) and maintainer scripts are not executed. Until a better solution is made available, all adjustments that are normally executed by maintainer scripts must be handled manually (e.g. using the solution @James-Carroll proposed in the previous comment).

4

Thanks. The solution by @James-Carroll works fine. It is not very satisfactory IMO. The promise of the .deb is that you can use the functionality it is supposed to provide. As is, you never know. In this case it is rather obvious, but in other cases the hook fix more subtle issues and thus you have a partially function snap. If there is a good reason why it is impossible to run the hooks, possibly snapcraft can warn that the package has hooks? That would have saved quite some time …