Why are snap layouts limited to 15 entries?

snap
1

I encountered this reworking the egmde-confined-desktop snap to use layouts, but the limit of 15 seems hard to work around. What I tried to use was:

layout:
  /usr/bin/qterminal:
    symlink: $SNAP/usr/bin/qterminal
  /etc/gnome-chess:
    bind: $SNAP/etc/gnome-chess
  /usr/share/gnome-chess:
    bind: $SNAP/usr/share/gnome-chess
  /usr/share/gnuchess:
    bind: $SNAP/usr/share/gnuchess
  /usr/share/gnome-mahjongg:
    bind: $SNAP/usr/share/gnome-mahjongg
  /usr/share/kodi:
    bind: $SNAP/usr/share/kodi
  /usr/share/games:
    bind: $SNAP/usr/share/games
  /usr/games:
    bind: $SNAP/usr/games
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/pulseaudio:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/pulseaudio
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/samba:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/samba
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/qt5:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/qt5
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/dri:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/dri
  /usr/share/applications:
    bind: $SNAP/usr/share/applications
  /etc/glvnd:
    bind: $SNAP/etc/glvnd
  /etc/fonts:
    bind: $SNAP/etc/fonts
  /etc/xdg:
    bind: $SNAP/etc/xdg
  /usr/share/X11/xkb:
    bind: $SNAP/usr/share/X11/xkb
  /usr/share/fonts:
    bind: $SNAP/usr/share/fonts
  /usr/share/glvnd:
    bind: $SNAP/usr/share/glvnd
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/mir/client-platform:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/mir/client-platform
  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/mir/server-platform:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}/mir/server-platform

But that fails to upload to the store:

Launchpad uploaded this snap package to the store, but the store failed to
scan it:

  too many defined layouts (21 > 15)

Each of these entries serves a purpose and there’s no obvious way to lose six entries from this list, for example:

ls /snap/core/current/usr/lib/x86_64-linux-gnu/ | wc -l
116

suggests that

  /usr/lib/${SNAPCRAFT_ARCH_TRIPLET}:
    bind: $SNAP/usr/lib/${SNAPCRAFT_ARCH_TRIPLET}

wound be a Bad Idea :tm:

Is the limit of 15 arbitrary? Could it be relaxed?

2

while i understand that layouts are a hit on the hosts ram, 15 feels really very limited …

i did not bother to upload the snap below to the store (since it is just a proof of concept) … but this uses ~400 layouts lines and seems to work fine from rpi over a qualcomm arm64 board to qemu amd64, all between 1-4GB RAM:

3

It isn’t exactly arbitrary but it also isn’t based on solid use case data (but one factor was considering that there might be scores of snaps installed, each with up to 3 revisions that might have their mount namespace setup). This check is something that @zyga-snapd and agreed would be a good check to avoid abuse, but I don’t recall how we landed on this number. @zyga-snapd, do you recall? Perhaps there is a better number?

4

i vote for 500 :slight_smile:

5

It is likely significant that both snaps mentioned above are “desktops” - which are complex compared to the more common “single application” snaps. But I doubt they are the only complex case that will be encountered.

I don’t know how serious the memory pressure might be: obviously many current snaps have stayed under the 15 limit. And on low memory systems there are likely fewer than scores of snaps installed.

Another, no doubt more complicated, option would be to allow a higher number following a manual review.

6

The memory constraints IIRC only happen when we have to install or modify the snap mount ns, it’s not a constant memory cost during runtime.

7

If that’s correct, I’ll second @ogra’s suggestion of 500.

8

Without @zyga-snapd’s input, I’ve conservatively increased this to 30 for now.

1 Like
9

I think that’s fine. This is not hard science. Having said that, we would benefit from having something other than layouts at our disposal. Layouts have performance and complexity constraints.

10

I’m currently having this issue with 36 layouts. Would it be possible to raise the limit to something harder to run into?