How to snap packages that provide "extra" files to be used by something else

Christian Ehrhardt christian.ehrhardt at
Thu Aug 4 13:16:01 UTC 2016

while thinking about what I could experiment with snapping next I checked
what I still use some external repositories for - as I considered those a
great list of opportunities.

One that I found there was my printer driver which consists of these
packages [1] provided by [2].
But thinking about how that would fit into the snap world gave me a hard
time, so I thought I better write it up for discussion. I mean I can only
win, either by learning or by identifying something that we can convert
into a valid feature request.

The reason I thought this might be non-standard in regard to snaps is, that
most of the functionality provided by these packages is achieved by placing
files for other programs to pick it up. Some examples might be:
- cups ppd files - /usr/share/cups/model/suld/ML-1740.ppd.gz
- special cups filters - /usr/lib/cups/filter/pstosplc
- or even libs for sane - /usr/lib/sane/

Now that doesn't fit in the (otherwise really great) sandboxing into ~/snap
or /snap.
Because in this case others programs should be able to pick up these files
in common paths.

It doesn't really qualify for an interface [3] as I thought to understand
them so far.

It might be somewhat close to the "home" plug in some ways - so maybe there
lies the rescue.
Yet the home plug it is more about the snap being able to reach out and
not "others" being able to pick up the files of the snap.

So what would be the preferred way to solve such issues in general when
creating a snap?

Thinking about it a bit further, even man-pages could be considered to fall
in a very similar category right?

Looking forward to learn, kind regards,


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Snapcraft mailing list