[cups.bugs] [LOW] STR #2949: Tell in the documentation/man page/help output of cupstestppd that CUPS accepts all PPDs which pass "cupstestppd -r" and does not accept PPDs which fail this cupstestppd call

[Johannes Meixner]

Hello,

On Sep 18 19:07 Till Kamppeter wrote (shortened):
> What I mean is that if you create a print queue with a PPD, CUPS will
> check whether the PPD is sane and in the case that it considers the PPD
> broken (non spec-conforming enough) then it will not use the PPD and set
> up a raw queue instead.

Really a "raw" queue?

Then it may have changed because some time ago (Nov 2003)
it became a queue with a "System V style interface script", see
http://osdir.com/ml/printing.cups.general/2003-11/msg00406.html
------------------------------------------------------------------
it seems the lpadmin command does some magic autodetection
regarding PPDs versus interface scripts:
   echo "foobar" >/tmp/broken.ppd
   lpadmin -p broken -v file:/dev/null -P /tmp/broken.ppd
results the queue to be set up with an interface script
(/tmp/broken.ppd was copied to /etc/cups/interfaces/).
------------------------------------------------------------------

For the reason at that time see
http://osdir.com/ml/printing.cups.general/2003-11/msg00427.html
(I didn't find those mails on http://www.cups.org/newsgroups.php)
------------------------------------------------------------------
.... the filename does not matter (cupsd doesn't get it,
just the file data itself), so the scheduler reads the
first line from the file and sees if it identifies itself
as a PPD file.

Once the PPD file is accepted, the scheduler attempts
to load the PPD file with ppdOpenFile(), and if that fails
it spits out an error to the error_log file similar
to what you'd see from cupstestppd.
------------------------------------------------------------------

At that time I filed
http://www.cups.org/str.php?L438


> What I want to do is to use cupstestppd to check
> already before creating a queue whether CUPS will accept a PPD for
> creating a queue, especially I want to be able to do this check also on
> machines without running CUPS daemon (for example the OpenPrinting server).

For me the whole stuff looks somehow "upside down".

Why should one need to run cupstestppd at all before?
The "lpadmin" command (or equivalent CUPS library calls)
should exit with an error instead.

I think the root cause is how the '-m' option works for "lpadmin":
" -m ... Sets a standard System V interface script or PPD file"
which means there is some magic to fall back to a "System V
interface script" when the input doesn't look like a PPD.
I think this magic is the root cause of Till's trouble.

If '-m' would only be valid for a PPD file and '-i' must
be used in any case for a "System V interface script",
then "lpadmin" could exit with an error if a PPD is broken.

But now there is the magic and we must keep it for
backward compatibility.

But I do not understand why the scheduler could not do
the following:

1:
The scheduler reads the first line from the input
and sees if it identifies itself as a PPD file.

2a:
If it does not identify as a PPD file,
the input is used as "System V interface script".

2b:
If it does identify as a PPD file,
the scheduler attempts to load the input stream
with ppdOpenFile(), and if that fails
it spits out an error to the error_log file
and does not set up (or change) the queue at all.
Ideally (if possible at this stage) the scheduler responds
to the client (i.e. to the "lpadmin" command or whatever
CUPS library call from the client) with an error so that
the client knows that the action had failed.

Perhaps the scheduler responds to the client "success"
once the PPD file is accepted (i.e. when it identifies itself
as a PPD file) even if the subsequent ppdOpenFile() fails
and then all the scheduler could do in this case is to
fall back to set up a "raw" queue because the scheduler
has too early closed the connection to the client.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex