Hi, On Wed, 2022-03-30 at 15:55 +0200, Zdenek Dohnal wrote: > On 3/30/22 03:26, Michael Catanzaro wrote: > > (removing users@xxxxxxxxxxxxxxxxxxxxxxx)... > > > > On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal > > <zdohnal@xxxxxxxxxx> wrote: > > > Unfortunately there is no clean upgrade path to solve the migration > > > automatically because of unrealistic requirements such as: > > > > > > - the USB device would have needed to be plugged in and turned on > > > during the update > > > - %post scriptlets don't work the same way on immutable Fedoras as > > > on Fedora Linux, and other upgrade possibilities such as Leapp don't > > > support Fedora upgrades AFAIK, > > > the fix has to be done manually. > > > > > Hi Zdenek, > > > > First, thanks for your work on preparing Fedora for CUPS 3.0 and > > driverless printing, and for helping me with the printer and scanner > > bug reports I reported after I discovered this broke my printer after > > upgrading to F36: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2066528 > > https://bugzilla.redhat.com/show_bug.cgi?id=2069277 > > > > Hopefully my experience after removing my old print queue and > > switching to the CUPS temporary queue is an anomaly. I know we don't > > *expect* users to have this much trouble. That said, even if > > everything goes as expected, requiring users to remove the original > > broken print queue is unfortunate. Leaving a broken scanner device > > around is too. > > > > I understand it is difficult to seamlessly upgrade users from F35 -> > > F36 due to the intrusive nature of these changes. That said, I think > > it's worth discussing whether a smoother upgrade is possible, because > > otherwise I expect a large number of complaints from users. An > > installed one-shot systemd service would avoid the need for any %post > > scriplets, for example. > > That could help us on immutable systems - but I'm not sure when the > service should run - I would expect it would run once a certain CUPS > version is on the system, but I'm not sure how to make it run only once > when it is installed without any %post/%triggerin in RPM. And what > should trigger the run of the service? > > Maybe an idea? The service will be brought up by udev rule - if action > 'ADD' happens during restart as well, the daemon should be loaded during > machine restart and when the printer is turned on - it will be run only > for IPP-over-USB device, construct the URI for the device and then try > to find the URI among local permanent queues. WDYT? Sounds reasonable, it probably isn't too bad to do a little bit more work here and run a migration script every time a printer supported by ipp-usb is plugged in. Not sure, maybe one could do that from inside ipp-usb. Or, possibly by adding a new (template) service that is launched by systemd to the udev rule, e.g. ENV{SYSTEMD_WANTS}+="ipp-usb-migrate@.service" to the udev rule. That way a script can be executed that receives the sysfs path of the printer (%I argument). If that information is enough to delete the queue from cups, then this might be a solution to the issue. And, one can still touch a file to skip running the script the next time the printer is discovered. Benjamin > > > Alternatively, could we find a way to disable the classic drivers if > > the printer supports ipp-usb? > > Hmm... what I can think of we could come up with deny lists for classic > driver projects (hplip, gutenprint, sane-backends), so users could > define idVendor and idProduct and reject the device in the classic > driver. However this would fit better the scanning stack, since there is > automatic device discovery for classic drivers. > > For printers permanent queue installation with a classic driver always > requires user intervention - IMO we should not block users which > explicitly want to install print queue with classic driver. > > > > > > - the USB device would have needed to be plugged in and turned on > > during the update > > > > I understand the problem is you don't know whether the printer > > supports ipp-usb unless it's on, right? Therefore, a one-time upgrade > > script has no way to know whether the print queue should be deleted or > > not? > Exactly. > > > > Perhaps it would be possible to delete the print queue that uses the > > traditional driver whenever support for ipp-usb is detected? > Yes, that could be possible, but it will work only if the device is > turned on when the service is started. > > I don't know enough about printing to say whether that is a reasonable > > suggestion or a ridiculous one. Just brainstorming. > > No problem, it helps me to think about the problem from another angle. > > > > > Michael > > > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > -- > Zdenek Dohnal > Software Engineer > Red Hat, BRQ-TPBC > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
