The common behavior for ipp-usb is that if ipp-usb is running, it keeps USB port of ipp-over-usb device (a device capable of driverless printing) for itself, which breaks already installed print queues which uses classic drivers and SANE backends, which don't use driverless scanning protocols.
Behavior of print queue breakage:
- the old queue is visible, but when a print job is sent to the old queue, it fails because the queue (its backend to be specific) cannot claim the device
Behavior of SANE backend breakage:
- the old device is visible, but scanning doesn't work because the backend cannot claim the device
The possible solutions are:
- redesign ipp-usb to don't claim the USB port by default, but only when there is communication to do - this would let the old setup working
- (future when print drivers go away) remove old print queues by some daemon/script
- prepare a migrate path right now, which will remove the old print queue once IPP-over-USB is connected (IPP Get Printers -> check model name in device-uri attribute and compare with model from libusb).
- SANE backends will need to have quirks functionality, which will stop advertising the broken devices
Currently I would prefer point A) and I'm discussing the issue with upstream.
The issue affects any installation with ipp-usb (ipp-usb is in repos since Fedora 32) - version: rawhide is just a placeholder.
This was originally accepted as a blocker bug, in bug 2066528, and in this blocker discussion:
However, since then, ipp-usb dependency was removed in F36:
These two updates are now stable, and I verified that Fedora-Workstation-Live-x86_64-36-20220406.n.0.iso doesn't contain ipp-usb, nor ipp-usb gets installed if you update an F36 Beta installation. So the blocker status is now removed.