Include contents of .deb package in snap

[svet]

I have a snap with a core18 base, but need to use a more up-to-date version of libsqlite3 than what’s. I’m guessing that my best option is to manually install the library from a more up-to-date version of the relevant .deb file? E.g. http://ports.ubuntu.com/pool/main/s/sqlite3/libsqlite3-0_3.31.1-4_${ARCH}.deb.

It seems that I can do that using the (smart) dump plugin by passing the URL of the .deb file, like this:

  libsqlite:
    plugin: dump
    source: http://ports.ubuntu.com/pool/main/s/sqlite3/libsqlite3-0_3.31.1-4_${ARCH}.deb

Is there a reasonably elegant way to incorporate the arch dependency in this? I do need this to work on multiple architectures, so I can’t hardcode that. But it doesn’t seem that I can use environment variables in the URL for the dump plugin. Is my only option to substitute this with a reasonably elaborate script, like this one:

mmtrt/wine-platform-6-staging-snap/blob/main/snap/snapcraft.yaml#L28

Any advice welcome, also with respect to better solutions to the overall problem I described above.

[ogra]

how about:

Alias request for snap 'google-cloud-cli-arm'

The cleanest solution, presuming you have both AMD64 and ARM64 systems, is to build the snap on both systems producing two separate snap files, one containing AMD64 binaries, the other containing ARM64 binaries. The store will automatically deliver the correct file to the client as appropriate. Both architectures will have the same name in the store. To make your snapcraft.yaml work with this, you likely want something similar to: parts: google-cloud-cli: plugin: dump source: o…

this is still kind of hardcoding the arch in the package name, but will conditionally pick the right thing at least …

[svet]

Great yeah, that should do it! Indeed not ideal, but it’s less work/more maintainable than coding an installation script. Thanks for the tip.

[jamesh]

If the newer libsqlite3 is available in a PPA somewhere (possibly one you create yourself), you could configure your snapcraft.yaml to use packages from that repository as discussed here:

Snapcraft package repositories | Snapcraft documentation

You’d then be able to pull in the newer libsqlite using stage-packages: as normal. I’d strongly suggest using a backport of the package rather than pulling random debs from more recent releases. While it might sometimes work, you might also pull in binaries that depend on a newer version of glibc than what is provided by the base snap you’re using.

[svet]

Right, so first off I had a go at the per-arch source that @ogra pointed to. This worked, though the correct syntax is

    source:
      - on amd64: <amd64-source.deb>
      - on arm64: <arm64-source.deb>

This, as @jamesh alluded to, threw a glibc version mismatch error when actually trying to use that version of sqlite. So I’m keen to try the PPA approach, but for now I’m not totally sure where to look. The most obvious place, bionic-backports, doesn’t include libsqlite3. I appreciate that this is tangential to the original question, but do you have any good pointers with respect to backport PPAs? It’s not really a world I’m very familiar with. In fact at this rate it’s tempting to switch to base core20, though I’d rather not go that way yet.

[ogra]

well, if you use a PPA you can as well build from source

it shouldn’t take a lot more than (this is from an old package of mine. you might want to look for a newer version if needed):

  sqlite:
    source: https://www.sqlite.org/2016/sqlite-autoconf-3130000.tar.gz
    plugin: autotools

[svet]

That’s a good point @ogra. Your suggestion actually did the trick nicely! (and yes, just grabbed the newer source URL from https://sqlite.org/download.html)