Description of problem: Our product, Codehost BrightQ, introduces a new alternative print command, and uses the alternatives mechanism to cleanly install it on Redhat and other distributions. However, starting with RH9, we get Python error messages on the console every time the printing system init script is restarted (/etc/rc.d/init.d/cups start). This seems to be caused by the naming convention for our command (pjm), while the scripts expect something of the form lpr.<system>. The scripts should handle this gracefully and not crash if there is no dot in the filename. Version-Release number of selected component (if applicable): Happens with 0.6.47-1 How reproducible: Introduce a new alternative printing command, using update-alternatives, and restart the printing system through the init script. Steps to Reproduce: 1. Define a new 'print' alternative with update-alternatives 2. Make the new alternative the current selection 3. Restart the printing system through the init script Actual results: Stopping cups: [ OK ] Starting cups: Traceback (most recent call last): File "/usr/sbin/printconf-backend", line 7, in ? import backend File "/usr/share/printconf/util/backend.py", line 48, in ? which = cups_import.which_spooler () File "/usr/share/printconf/util/cups_import.py", line 191, in which_spooler which = l.split ('.')[1].strip () IndexError: list index out of range [ OK ] Expected results: No error. Additional info: The which_spooler function in cups_import.py needs to first check for the presence of the dot before splitting the string.
Well, redhat-config-printer only knows how to deal with LPRng and CUPS in conjunction with foomatic. In rawhide, redhat-config-printer will have cups as a requirement.
Well, yes, it's all fine and dandy, but this bug report was about an unnecessary hard crash in your software, not a request for support of a printing system or a new set of filters. Whether or not it knows how to deal with it, I don't think it's ever acceptable for printconf to just completely bail and abort all operations while the simple fix is a single line of Python code. If anything else, error handling is a safe coding practice. We found a way to work around this in our code, so it's not that much more of an issue on our side, though the side effects with earlier versions of our software are really annoying (printconf just crashes and doesn't finish doing what it is supposed to do, like regenerating the printcap files).
Of course, the fix isn't necessarily a single line of python code: if the spooler isn't cups, redhat-config-printer is out on a limb and has no idea how to drive it.
I completely agree. However I still think it would be better to gracefully exit with an error message in such a case (which is trivial to detect), instead of the current catastrophic crash.