Bug 131097

If only one USB printer is used, see
http://www.cups.org/str.php?L1267
how you can avoid at least one situation which disables the queue
(i.e. use the generic DeviceURI "usb:/dev/usb/lp0").

You can switch YaST to use generic DeviceURIs for USB printers.
Or via command line use "lpadmin -p QUEUE -v usb:/dev/usb/lp0"
to change the DeviceURI to the generic style.
Again: This works o.k. only if you have only one USB printer.

See for example the mail
http://www.easysw.com/cups/newsgroups.php?s5622+gcups.general+v5627
and the next two mails for an explanation why the queue must be
disabled by default in case of a data transmission error.

In the next CUPS version the USB backend will do endless retires
in any case and additionally the next CUPS version adds an error
policy which allows to configure how CUPS handles these errors
(something like abort retry ignore) => will be FIXED.

It was not a real transmission error, the device was simply not there
(turned off) 

Endless retries etc. are wrong too. disabling is ok when the device
is not there. But what it should do is to just watch
for the hotplug event when it sees the USB device first and then enable the printer if disabled. Basically I think you need to add a little hook
to the USB hotplug script that handles this case.

Kay might have some input on this.

Regarding comment #2:
I understand your request.
It comes very often on the CUPS mailing list.
The request looks easy but if it was so easy,
it would have been already implemented.

Regarding "watch for the hotplug event":
I think it is up to the backend to do this.
As far as I understand the CUPS design it is not the cupsd
which should care about the plain data transmission to the recipient
because this is delegated to the various backends, see
http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html
"The Backends"

Therefore it is o.k. when the backend keeps running and
polls each 30 seconds for the printer - this should not cause
a too high system load.

From my point of view it may be nicer than polling when the backend
falls asleep and is waked up by a hotplug event - but does this work
in any case - even without special hotplug/udev/HAL deamons running?

In any case:
We won't do such changes for 10.0
=> Enhancement request for 10.1 and reassigned to CUPS maintainer.
 

hotplug/udev/hal is running on SUSE and that is what matters.

I wouldn't change anything with cups itself, but just add a script
on printer hotplug that looks for the associated queues and when
they are disabled automatically enables them.

Ahh!
Thanks for clarification.

Regarding "automatically enable":
What if the admin had disabled the queue intentionally?
It should stay disabled even if a normal user unplugs
and re-plugs the USB cable.

I think the CUPS error policy (see comment #1) is the better
way to handle it.

I think it's reasonable to let cable hotplug/printer reset overwrite queue disable. If someone has access to the hardware like this they're basically like the admin. In theory you could implement two different disabled states to distingush it, but that would be probably overkill.

Polling is definitely not a good idea. I don't want to wait 30seconds
and it's just dumb in general.

RH plugs into the HAL callout mechanism to notify cups about printer changes:
  http://cvs.fedora.redhat.com/viewcvs/devel/hal-cups-utils/

Thanks. To disable the printer, as soon as an error occurs, is done with intention.

We had a long description regarding this in the administration handbook. But first was this chapter reduced to some basic hints, now this book no longer shipped. Thats were we must start to point at, if we blaim and cry. :-(
Next thing is, that printing isn't included in our free "installation support" for customers...

Anyway: I accept your point of view and your bugreport is valid. But our explanation, why we won't change the behavior isn't false neither. So we don't change the behavior here and keep being in sync with the CUPS project itself.
This contains the advantage that our users can ask at public mailing lists, why this-and-that is not working in CUPS, and they can expect to get a response from there.

Thanks for understanding.

This problem should be fixed in CUPS 1.2 which is now released.
http://www.cups.org/str.php?L1267
Will there be an update for 10.1 or at least for SLES10?

No. No updates for our old products.

cups-1.2.0 is not stable, at least not for our needs. E.g. Browsing is no longer working after a "reload" of cupsd is done. 
It is not possible to use an old 1.1.x configuration with cups-1.2.x, they are incompatible. Other fundamental changes took also place ==> a smooth upgrade is neither possible.