Slots with architecture dependent paths

snapcraft
1

Hi,

I’m going to share some files between two snap packages, and the files lives in $SNAP/usr/lib/*architecture*-linux-gnu, e.g /snap/[...]/usr/lib/aarch64-linux-gnu/.

How can I deal with this except from sharing the whole usr/lib directory?

2

You can use the magic-replacement keyword $SNAPCRAFT_ARCH_TRIPLET which will be the architecture triplet of the snap you’re building.

Note: this only works when building the Snap. You cannot use it when running the built Snap once installed. That is it is a Snapcraft (the build utility) feature, not a Snap Packages feature.

3

And therefore not a solution to this problem. :wink: But thanks for the input. :blush:

4

use a command-chain wrapper then to call “arch” and set a variable based on its output that you can consume …

5

Hi,

Not sure if that will help either:

slots:
  _name_:
     interface: content
     [...]
     read: ....path

A wrapper can’t be used for this?

6

make “path” a non-architectural thing and use a layout to re-map to the right place ?

7

You could make the content interface point to a symlink in $SNAP which is arch dependent, i.e. when building the snap on one architecture, make the symlink point to one location, and when building on another architecture make the symlink point somewhere else (but the location of the symlink is always the same)

1 Like
8

Oh, wasn’t aware that symlinking would work. Guessed that content of the plug would be a «read-only» file system and anything outside of this file system would be unreachable for a connecting snap.

9

The content of a content interface can be whatever the snap has access to as identified by the read or write settings for the interface. So you can share things from $SNAP_DATA, etc. that are readable. Whether or not the other end of the snap can read the files or write them depends on if you use read or write and whether the underlying files are writable.

10

Yeah, but this is the case with symlinking:

Producers snap file system:

$SNAP 
  |- bin
    | - ...
  |- etc
    | - ...
  |- lib
    | - ...
  |- usr
    |- lib
      |- x86_64-linux-gnu
  |- non-arch-symlink-name (of $SNAP/usr/lib/x86_64-linux-gnu)

Producers slot:

slots:
  my_x86_64_linux_gnu:
     interface: content
     [...]
     read: $SNAP/non-arch-symlink-name

Consumers plug:

slots:
  my_x86_64_linux_gnu:
     interface: content
     [...]
     target: $SNAP/usr/lib/extra

consumer $ ls -al $SNAP/no-arch-symlink-name == producer $ ls -al $SNAP/usr/lib/extra

11

Sorry I’m not quite parsing what this is meant to say, are you saying you weren’t able to get the symlink shared via content interface working ?

12

if it is a plug it shouldnt identify itself as a slot :wink:

13

I suspect you won’t be able to use a symlink as the content interface source directory: there is code in snap-update-ns specifically to check that there are no symlinks. It’s part of the defence against less privileged code tricking snapd into performing an unwanted mount.

I think the best option would be if Snapcraft let you use $SNAPCRAFT_ARCH_TRIPLET slot definition, and expanded it to the relevant value in the resulting snap. That would probably make a reasonably straight forward “first pull request” for Snapcraft if anyone is interested.

1 Like
14

Ah, sorry, that was just a mistake in the example.

15

I guessed that too. :slight_smile: But do the arch-triplet reflect the output form arch, so it can match x86_64 or is it the amd64 output? Tried to see if the docs said anything, but it doesn’t explain the value in details.

16

When it does expand $SNAPCRAFT_ARCH_TRIPLET, it is expanded to the GNU style architecture identifier. So for an amd64 build, it will expand to x86_64-linux-gnu.

1 Like