[cups] Searching recursively for backends and filtes inside ServerBin directory?

Michael Sweet msweet at apple.com
Wed Oct 15 13:31:52 PDT 2014


Mario,

On Oct 15, 2014, at 4:06 PM, Mario Sanchez Prada <mario at endlessm.com> wrote:
> ...
>> Moreover, backends tend to support common interfaces/transports and are not
>> generally included as part of a driver.
> 
> Well, I did found a couple of cases where they are indeed included as
> part of the drivers, like the Canon InkJet drivers cnijfilter2 and
> cnijfilter-common, which install the following CUPS backends:
>   cnijfilter2: /usr/lib/cups/backend/cnijbe2
>   cnijfilter-common: /usr/lib/cups/backend/cnijbe
>   cnijfilter-common: /usr/bin/cnijnetprn
>   cnijfilter-common: /usr/lib/cups/backend/cnijnet
>   cnijfilter-common: /usr/lib/cups/backend/cnijusb

Yes, these are examples of how not to do drivers... :/

> ...
> And there's yet another type of executables (that I forgot to mention
> in my previous email) that are sometimes provided by specific printer
> drivers too: the driver programs under /usr/lib/cups/driver. For
> instance, you can check the printer-driver-escpr from Debian/Ubuntu in
> http://packages.ubuntu.com/trusty/printer-driver-escpr, which installs
> the following files in the system:
> 
>  /usr/lib/cups/driver/escpr
>  /usr/lib/cups/filter/epson-escpr-wrapper
>  /usr/lib/cups/filter/epson-escpr

Driver interface programs are deprecated since (at least) CUPS 1.6. They caused a lot of performance problems, and vendors *should* be using driver info files (for the PPD compiler) or tarball archives instead...

> ...
> So, all in all it seems that the critical thing is to find a way to
> deal with additional driver backends living outside of
> /usr/lib/cups/backend, as filters and driver programs in /usr/lib/cups
> can be easily "fixed" by updating the paths in the PPD files. Assuming
> we find a secure way to do that in our -fairly controlled- system,
> would you see any missing piece in the puzzle? Or even better, do you
> think there could be a way to find such a controlled way to implement
> this upstream (extending the search path for bakends)?

We hope to someday eliminate printer drivers, and actively discourage vendors from developing printers that require custom backends in the first place.  So I don't see us investing any time in supporting driver-specific backends.

Probably your best bet is to provide a wrapper program/script in /usr/lib/cups/backend that looks in your own backend directory for third-party backends and runs them as needed.  That would involve the fewest changes to the third-party code, mainly just the path stuff if they are hardcoded...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair



More information about the cups mailing list