Hi,
On Wed, 2022-03-30 at 15:55 +0200, Zdenek Dohnal wrote:
On 3/30/22 03:26, Michael Catanzaro wrote:
> (removing users@lists.fedoraproject.org)...
>
> On Wed, Mar 23 2022 at 01:58:33 PM +0100, Zdenek Dohnal
> <zdohnal(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure