Snapping CUPS drivers as plugins

snapcraft
1

Hi,

I have already posted my first question about snapping CUPS. Now I have another question:

The printing snap will contain CUPS, cups-filters, and MuPDF, but not a collection of printer drivers and PPD files, to keep the snap small and light, so that one can also easily use it on IoT appliances and mobile devices. For this kind of devices the printer manufacturers have also introduced several standards for driverless printing: IPP Everywhere, Apple AirPrint, Mopria, and WiFi Direct (AFAIK).
But even with that many driverless printing standards there are enough legacy printers requiring drivers and also in the future such printers will probably continue to get onto the market. Therefore the printing stack snap should also support printer drivers.
My idea is to allow printer driver snaps as plugins to the printing stack snap. The user can install one or more printer driver snaps on his system running the printing stack snap. The printing stack snap sees the installed printer driver snaps and uses them for setting up supported printers.
Printer driver snaps could be put up in the snap store and manufacturers who want to support their printers under Linux and on snap-based appliances can post their printer driver plugin snap there. This is a way to provide distribution-independent printer driver packages (and ones the interface is defined easier to implement for printer manufacturers than the former LSB approach).
So what I want to know is which interface in Snappy is the best to implement this.
I have one master snap (the printing stack snap) and this needs to support plugins which are other snaps and installation of a plugin snap should add files (including binary executables) to the file system of the master snap.
Important is:

  • The master snap does not have to know beforehand which plugin snaps exist. It must be possible to add a new plugin snap to the snap store without need to modify the master snap.
  • It must be possible to install any number of (different) plugin snaps to one installed master snap, allowing any number and combination of supported printers to be connected to one machine.
  • The plugins can contain binary executables, also closed source.

Would the “content” interface be suitable for this? If yes, could someone post links to documentation and/or examples which could help on the implementation? If no, is there any other suitable interface? Or should I post a feature request? And if so, where?
Thanks for any help.

Till

1 Like
2

To revive this thread, the answer to this question is already posted as a feature request on Launchpad.

1 Like
3

I think the content interface improvements that were discussed to support desktop themes in snaps might help here.

When implemented, this will allow you to configure the content interface such that multiple slots will attach to a single plug. In this mode, each plugin snap would provide a content interface slot exposing their plugin code, and the cups snap would provide a matching plug.

On the cups side, you could pick a directory where the slots would be exposed, which would expose a tree looking something like this:

contentdir/
  snap1/
    [files from first snap]
  snap2/
    [files from second snap]
  ...

The plugin snaps could control the snap1, snap2, etc directory names, but snapd might rename them if there are conflicts (it won’t be able to merge content from two snaps). Does this sound like something you could use?

1 Like
4

It does sound like a very similar use case. The content interface is indeed the way to go, @till.kamppeter.

5

Thank you very much.
This would work if on each installation, update, or removal of a plugin snap or of the printing stack snap itself a script is run which sets/updates/removes symlinks of the plugin’s files to the filters, backends, and PPD directories of CUPS. Is this possible? It would be something maintainer-script-alike, a script run on installation/update/removal of a snap.

6

There is some documentation covering the current interface. This will allow you to get started, but once @jamesh and @zyga-snapd finish the improvements that James mentions it will change slightly, but the underlying idea will remain the same: you have a snap that can see content from other snaps.

About scripts, yes, this will be possible in the near future. @pstolowski has been working on landing interface hooks, which is exactly what you want in this case I think: executables that can run when the interface is connected and disconnected (before and after, on both ends).

1 Like
7

Muito obrigado, Gustavo, I will look into this.