In bug LP: #1742565 a way for the snap to get the gnu arch triplet (like x86_64-linux-gnu) in addition to the SNAP_ARCH (amd64) is requested.
Many snaps use paths internally that use the triplet to find plugins or libraries which means that currently there are a lot of wrapper scripts that contain code like:
case $SNAP_ARCH in amd64) export TRIPLET=x86_64-linux-gnu ...
by providing this as an environment via
snap run we are one step close to the goal of getting rid of wrapper scripts.
The common case is that snaps are build using snapcraft with an ubuntu toolchain. In this case we know the triplet and PR#4477 implements a new SNAP_ARCH_TRIPLET environment.
The triplet is dependent on the toolchain used to build the snap. So in the general case someone may build a snap using a toolchain configured for x86_64-linux-musl. So providing this env for the general case requires help from the snap. The snap would have to provide a mapping table like:
amd64 x86_64-linux-musl i386 i386-linux-musl ...
for all arches it ships/cares about. Ideally auto-generated from snapcraft.
The use cases for this environment is mostly to find setup LD_LIBRARY_PATH to something like $SNAP/usr/lib/$SNAP_ARCH_TRIPLET/ and to configure plugin paths. One suggestion by @niemeyer was that we could write a ld.so.conf file inside the snap run environment that would setup the common paths automatically (like $SNAP/usr/lib/$SNAP_ARCH_TRIPLET/) so that there is no need to setup LD_LIBRARY_PATH at all anymore. This would not solve the export for plugins though but we may provide both.
So given the above, I would suggest we provide:
- SNAP_ARCH_TRIPLET for the common case
- a way for snaps to define their own triplet mapping (we need to discuss how this is defined, maybe simply via a yaml map in snap.yaml?)
- consider providing ld.so.conf pre-configured with the triplet