As you probably already know, snapcraft supports a range of plugins, designed to aid developers in making their snaps in an easier, faster, more transparent fashion. Plugins work with different programming languages and build tools, like Python, Java, Rust, Cmake, and others. By making complex things simpler, they can accelerate your projects.

One of the available plugins is the dump plugin, which “just dumps” contents from a specified source into your snap. Sounds quite simple, but this plugin can be extremely useful when you want to quickly package and test your application. Let’s see.

The dump plugin supports numerous formats

A typical use case where the dump plugin brings value is for developers who already have created and packaged code in the past. For instance, if you have already built your application as a Debian package, you may be dismayed by the notion of having to start all over again when building snaps. But this does not have to be so.

You can specify existing files available for different distributions as the source in the plugin declaration in the snapcraft.yaml file, and the contents will be automatically unpacked for the particular part. You may want to do this if you require a particular library that is not available in the distribution repository archives, or you need an old library that is no longer supported – a practical requirement for legacy applications.

Moreover, you may have a standalone application that bundles all its dependencies inside a single archive, and you just want to see whether it will work when packaged as a snap. Here, the dump plugin can be quite useful, as it lets you create and test a snap within minutes. It’s not only Debian packages, though. The dump plugin works with a range of sources, including rpms as well as zip and tar archives!

Practical example

A good test case would be the old WYSIWYG HTML/CSS editor called KompoZer. Active development of this application has ceased in around 2008, and it was available in Ubuntu archives until Pangolin (Ubuntu 12.04). Users who want to install this tool still will have to manually satisfy multiple dependencies and then install several Debian packages from Launchpad. These packages could conflict with the libraries on their systems.

The alternative is to package KompoZer as a snap. Without going into full details on how to package KompoZer, the dump plugin lets us quickly grab and extract the archives. In the snapcraft.yaml:

• Define a part (e.g. kompozer-data).
• Specify source for this particular part.
• Specify any stage packages that this part will require – the runtime libraries that the application depends upon (typically the long list of dependencies that you would have to manually satisfy).
• Provide any pull or build overrides – in some cases, applications may be built with hardcoded paths that would require breaking out of the snap confinement. You can manually modify these, as we will see in a moment.

Here’s a code sample:

parts:
 kompozer-main:
    plugin: dump
    source: https://launchpad.net/ubuntu/+archive/primary/+files/kompozer_0.8~b3.dfsg.1-0.1ubuntu2_amd64.deb
    stage-packages:
      - libatk1.0-0
      - libc6
      - libcairo2
      - libfontconfig1
…
  kompozer-data:
    plugin: dump
    source: https://launchpad.net/ubuntu/+archive/primary/+files/kompozer-data_0.8~b3.dfsg.1-0.1ubuntu2_all.deb
    override-pull: |
      snapcraftctl pull
      ln -sf ../../../../etc/kompozer/profile usr/share/kompozer/defaults/profile
      ln -sf ../../../../etc/kompozer/pref usr/share/kompozer/defaults/syspref

What do we have here?

First, we have the kompozer-main part. We extract the contents with the dump plugin, and then list all the different stage packages. If the application depends on libraries that are not available in the distribution archives, you can specify them too as separate parts, and grab them using the dump plugin.

For the second part – kompozer-data, we have a slightly different declaration. Namely, originally, this package comes with two hardcoded symbolic links pointing to /etc, which is not possible with a strictly confined snap.

Failed to copy '/root/parts/kompozer-data/build/usr/share/kompozer/defaults/syspref': it's a symlink pointing outside the snap.

So we override the pull process and manually re-link these – the override declaration is just a list of shell commands.

    source: https://launchpad.net/ubuntu/+archive/primary/+files/kompozer-data_0.8~b3.dfsg.1-0.1ubuntu2_all.deb
    override-pull: |
      snapcraftctl pull
      ln -sf ../../../../etc/kompozer/profile usr/share/kompozer/defaults/profile
      ln -sf ../../../../etc/kompozer/pref usr/share/kompozer/defaults/syspref

There could be some trial and error during the snap build process, and if you need help with how to go through these more quickly, please consult our tutorial on making development faster and then the follow-up guide with additional tips and tricks on this topic.

Architectures

Furthermore, you can also specify different sources to match the system architecture, like amd64 and i386, which means a single snap will work for users on these different platforms. This is quite handy, especially for legacy software.

    source:
      - on amd64: https://link/library_amd64.deb
      - on i386: https://link/library_i386.deb

Conclusion

The dump plugin may look like a simple helper tool, but it gives developers quite a bit of flexibility in how they package and test their software. If you already have compiled code, you can use it for quick & dirty tests, to assess compatibility, to retrieve libraries and legacy components that are not available in standard software channels, or even build custom applications that may contain data samples, tutorials or similar.

As always, we value feedback and comments, so we can make snapcraft even more extensible and useful to developers. If you’d like to share your ideas or suggestions, please join our forum for a discussion.

Photo by Christopher Burns on Unsplash.