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

[Mario Sanchez Prada]

Hi,

On Wed, Oct 15, 2014 at 9:31 PM, Michael Sweet <msweet at apple.com> wrote:
> [...]
>> 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... :/

I didn't know that, thanks for clarifying it. Unfortunately, I'm
afraid there are a bunch of drivers out there providing their own
backends... so far I could only saw HPLIP, Canon and some Samsung
drivers doing that, but there are probably more :/

>> ...
>> 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...

I see. That explains why I did only see this in the oldest drivers I
could find, and not in the newest ones.

>> ...
>> 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.

Ok. Makes sense. In our case we are interested in supporting already
existing drivers, so I guess we will have to find an intermediate
solution in the meanwhile for our specific needs anyway.

> 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

That sounds good. Will look into that option then.

Thanks!
Mario