Bug 15651

This defect is considered MUST-FIX for Winston Gold-release

This functionality would be VERY non-trivial to add, as the lprm output is
actually coming from lpd, so we would need a parser to parse a status request
before we made the removal request, which would significantly complicate the
workings of lprm.

Adding this functionality without changing any other behaviour would be a very
risky proposition.
I am going to send a feature request to the LPRng upstream, and closing this as
a wontfix.

Fixing a bug is an enhancement, and this is a bug - not an RFE.

Besides, adding checks for queues either in the daemon or lprm itself is a
little work, but very far from risky.

The spooler checks for spools, of course, it just doesn't tell
the client if it didn't find any, and changing the communtication
nature of lpd is the wrong thing.

The only Right Thing is to make a status request on the spooler,
parse the text block it returns, and figure out if it has that spool,
then make the remove call if it does, and drop an error if it doesn't.

This is not a trival problem, the complexity of lprm goes up by a second
network call and a parser, and adding this without breaking anything else is
not simple.

This IS an enhancement. There is no documented behaviour that says there will
be an error message, and it did not do it before. I've sent an enhancement
request
to the author. Just because you want it to do something does not mean there is a
bug
if it was not designed to do it.

It's clearly a bug not to report that a queue is non-existing - I don't see any
point arguing that. Saying otherwise would imply that e.g. gcc could quietly do
nothing if asked to operate upon a non-existing file... and that fixing that
would be an enhancement, not a fix. "Enhancement" in bugzilla means "new
functionality".

Back to the main topic:  Yes, I think it should do a new call if necessary.

It is not 'clearly' a bug.

the lprm behaviour is documented as:
       Lprm  will announce the names of any files it removes and is silent if
there are no
                                                                                            
^^^^^
       jobs in the queue which match the request  list.   If  the  job  being 
removed  is
       active,  the LPD server will stop printing the job and then restart
printing opera-
       tions.

So this is a special case (there are never any jobs waiting in a non-existant
spool).

Now admittedly, there are some lprm programs which behave differently, But that
is not the point. 

The point is that this would significantly change the internal behaviour of the
lprm that we ship, and could quite easily generate a bit of surprise on the user
end. The lack of response if a spool does not exist is not surprising to LPRng
users.

But if we put a parser into the lpr code, we have to change it every time the
lpd output format changes, and parsers are not simple code, it would be a
relatively large patch for a piece of funcionality that A) is not internaly
developed, and B) works now.

I have sent a feature request to the author, well see what he says about adding
it, but adding a parser at the moment is much more likely to increase bugs than
to close this minor issue.

So I am NOT adding a parser because a trivial error issue does not warrant that
kind of rewrite for a piece of external code.

You don't need a fullblown parser at all, but if you want to close it as
"WONTFIX" feel free.

Some bugs go that way.

Ok I'm checking my depends packages, and the conces seems to be wontfix so I'm
closing this reopen if I've closed it wrongly.