[Printing-architecture] PAPI bug: "lpstat -v" uses /etc/printcap on CUPS system

[Printing-architecture] PAPI bug: "lpstat -v" uses /etc/printcap on CUPS system

[Till Kamppeter]

I am using the PAPI with the psm-ipp backend as CUPS is the spooler on
my Mandriva box. By default CUPS writes a pseudo /etc/printcap for
backwards compatibility. Therefore I did not get aware of the problem in
the first tests.

This writing of /etc/printcap can be turned off by putting a line only
containing "Printcap" into /etc/cups/cupsd.conf and then restarting the
CUPS daemon. After that I also deleted the last /etc/printcap which CUPS
keft over and entered

lpstat -v

again and then no print queue was listed. I cannot even print any more.
the "lpr" command tells me that the printer which I have specified does
not exist.

This means that without /etc/printcap libpapi does not work at all. And
as in CUPS printer enumeration is done via IPP and not via /etc/printcap
this is a real bug in libpapi.

The psm-ipp plug-in even has a function which uses an IPP extension of
CUPS to enumerate the printers, papiPrintersList() in libpapi-ipp/printer.c.

Very strange is also the output of

strace lpstat -v > x 2>&1

when CUPS does not write /etc/printcap. I have IPP set as compile-time
default for the print service module and in the strace output one can
see that lpstat fails to open /etc/printcap and then it decides to try
opening /usr/lib/psm-_all.so which also does not exist and probably
never existed. Why does lpstat check /etc/printcap? All communication
with the printing system should be done through the PSM backends, in my
case through /usr/lib/psm-ipp.so and this is never called in this case.

   Till