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? Does the action
'ADD' is
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
