Classic snap without enable-patchelf got smaller package size and better performance

snapcraft
1 
name: codium-insiders
base: core24
version: '1.97.0.25026-insider'
summary: Code editing. Redefined.
description: |
  Binary releases of Visual Studio Code - Insiders without branding/telemetry/licensing

platforms:
  amd64:
  arm64:

grade: stable
confinement: classic
compression: lzo

apps:
  codium-insiders:
    command: bin/codium-insiders --no-sandbox
    desktop: meta/gui/codium-insiders.desktop
    common-id: codium-insiders.desktop

  url-handler:
    command: bin/codium-insiders --open-url --no-sandbox
    desktop: meta/gui/codium-insiders-url-handler.desktop

parts:
  codium-insiders:
    plugin: dump
    source:
      - on amd64: https://github.com/VSCodium/vscodium-insiders/releases/download/${SNAPCRAFT_PROJECT_VERSION}/VSCodium-linux-x64-${SNAPCRAFT_PROJECT_VERSION}.tar.gz
      - on arm64: https://github.com/VSCodium/vscodium-insiders/releases/download/${SNAPCRAFT_PROJECT_VERSION}/VSCodium-linux-arm64-${SNAPCRAFT_PROJECT_VERSION}.tar.gz
    source-type: tar
    # stage-packages:
    #   - libasound2
    #   - libatk-bridge2.0-0
    #   - libatk1.0-0
    #   - libatspi2.0-0
    #   - libcairo2
    #   - libcanberra-gtk3-module
    #   - libcurl3-gnutls
    #   - libcurl3-nss
    #   - libcurl4
    #   - libdrm2
    #   - libgbm1
    #   - libgl1
    #   - libglib2.0-0
    #   - libgtk-3-0
    #   - libibus-1.0-5
    #   - libnss3
    #   - libpango-1.0-0
    #   - libsecret-1-0
    #   - libxcomposite1
    #   - libxdamage1
    #   - libxfixes3
    #   - libxkbcommon0
    #   - libxkbfile1
    #   - libxrandr2
    #   - libxss1
    # prime:
    #   - -usr/share/doc
    #   - -usr/share/fonts
    #   - -usr/share/icons
    #   - -usr/share/lintian
    #   - -usr/share/man
    #   - -usr/share/codium/chrome-sandbox
    # build-attributes:
    #   - enable-patchelf

Here is the snapcraft.yaml.

If enable the enable-patchelf, i need to add ton of stage packages to make this snap work.

But I accidentally discovered that without enabling patchelf, my snap still works and I don’t need stage packages at all.

I tried to find out why this happened and found this doc.

According to the documentation, classic snap will first try to load the library from base snap, and if that fails, it will try to load the library from host.

Obviously my snap can run because it uses the host library.

Now my question is, what are the pros and cons of this approach?

In my mind, classic snap equals deb/rpm/portable, so there seems to be nothing wrong with use host’s library?

Please give me some advice.

2

have you installed it on fedora, gentoo, manjaro, arch (or even Ubuntu 16.04) ?

snaps have to be self contained which means that your classic snap has to ship all libraries it needs to run inside and you need to make 100% sure to keep the runtime environment separated from the host to not accidentially leak libs from the outside into the snap or vice versa since it is very unlikely that the host system has the exact lib versions your app needs.

If it worked by sheer luck on your host machine that is likely an Ubuntu host, that doesn’t mean it will work on other OSes …

3

As Ogra says, the pro’s/con list would be pretty concise:

Pro’s: A smaller snap

Con’s: It only runs on the same distribution it was built (for, given Snapcraft can use LXD/Multipass to abstract this somewhat) and is all but guaranteed to fail elsewhere.

Simpler programs that might be e.g., entirely Bash scripts might fare better than others here, but most programs of any non-trivial complexity wouldn’t stand much of a chance unless they were written to be standalone and statically linked already.

Codium being Electron stands a fairly good chance because it’s heavily statically linked as is, which is how people get it working so well in e.g., AppImage formats - but as someone who snaps Electron (in strict), I’d encourage you to prefer patch-ELF fairly strongly because the sheer complexity of the code base means there’s plenty of random libraries that only get called in niche scenarios that’ll avoid testing but are statistically common enough in real use.

I’d say on this point, you should consider that while some .debs can cheat and run across multiple distributions (hello, Electron again) - the vast vast majority of deb’s/rpm’s are in distribution repositories that split them across distribution releases explicitly because the majority are incompatible, due to things like newer compilers and ABI/API in general.

4

I got it. Thank you all ！