If you want to print (or do printer administration) from a snapped application you add a plug to the “cups-control” interface, to connect to the domain socket of CUPS. The slot is most probably provided by the classic emvironment with a Debian-package-based CUPS installed.
Some time a go, I started the developemt of a CUPS snap:
First thought of it was to allow printing in an all-snap distribution like Ubunru Core, but also to provide a distribution-independent implementation of a printing stack on OpenPrinting, for everyone being able to use a printinf stack composed from the newest components. I brought it even to a first test release in the Snap Store.
Now Ubuntu development is going to provide more and more components of the Desktop distribution to be provided in snaps. Also CUPS should come from a snap soon.
Therefore I have picked up the developemnt of the CUPS Snap again and done a lot of bug fixes and improvements for better reliability and usability of the snap.
Now I was hitting into some problems with the interface:
- A snapped application has a plug to the “cups-control” interface. This leads to a CUPS installed from Debian packages into the base system
- If there is no such CUPS but the CUPS snap installed instead, “cups-control” should point into the snapped CUPS, so the snapped CUPS needs to provide the “cups-control” slot. There needs to by some kind of automatic switch for which CUPS is actually installed.
- CUPS does not provide only a domain socket (
/var/run/cups.sockin the case of CUPS in Debian packages) but also IP access via
localhost:631and also D-Bus services (AFAIK
/com/redhat/PrinterSpoolerat least). The interface needs to allow access to all of these channels for every snap with plug to “cups-control” but also to unsnapped (Debian-installed) applications.
- The “dbus” snap interface is not very well suited for CUPS as a client snap would need to connect to “cups-control” and two “dbus” interfaces, so 3 interfaces would need to get connected, therefore I like to have that all in one “cups-control” interface.
My request is to get the “cups-control” interface appropriately extended so that snapped applications have always full access to CUPS, independent whether CUPS comes from Debian packages or from the snap, and also that unsnapped applications have full access to CUPS, also to the D-Bus services.
Note that the CUPS snap will soon get renamed, from the current “printing-stack-snap” to “ipp-service-cups”.
I hope that this is possible to get implemented.