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

Christian Ehrhardt christian.ehrhardt at
Fri Aug 12 12:36:28 UTC 2016

On Fri, Aug 12, 2016 at 1:35 PM, Mark Shuttleworth <mark at> wrote:

> Interfaces should actually handle this case very well, as long as both
> sides of the file exchange are predictable. So I can imagine CUPS
> providing an interface to ingest PPDs and a PPD snap that consumes that
> interface making the PPDs available.
> In the next wave of landings, you'll see the ability to execute code in
> both snaps when an interface is being connected, allowing you to agree
> for example on filenames etc.

Ack: In any pure snap setup the interface based solution would have been my
way to go for this. And it certainly is the right one.

In the context of the request I was thinking more about snaps on classic
and how e.g. a "classic" system could pick up those.
Or turning around the statement: How a snap would ensure things are picked
up by the "host" in classic.

A generic solution for this isn't the most important feature - as it might
also break isolation more than we like.
So - if considered as a generic feature - this might just end up as one of
the constraints for snaps on classic.
But for a few common cases (like manpages see bug 1575593 I think we should
design and provide something that can be commonly used).

Looking forward for the next wave of landings then - maybe the "active
interface connect" if we want to call it that way would already provide
enough to solve it that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Snapcraft mailing list