[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#908500: cups-browsed: Please consider making cups-browsed a Suggests:



On 13/12/2018 19:45, Brian Potkin wrote:
On Mon 22 Oct 2018 at 08:54:52 +0200, Didier 'OdyX' Raboud wrote:

Control: reopen -1
Control: reassign -1 cups-daemon 2.2.8-5
Control: retitle -1 cups-daemon: Please consider making cups-browsed a Suggests
Control: affects -1 +cups-browsed

Le dimanche, 21 octobre 2018, 21.21:13 h CEST Debian BTS a écrit :
On Mon 10 Sep 2018 at 15:16:44 +0100, Brian Potkin wrote:
Package: cups-browsed
Version: 1.21.2-1
Severity: wishlist


With the introduction of cups 1.6.x the situation in respect to printing
to remote print queues and printers would have been dire without the
creation of cups-browsed. However, cups 2.2.4 and later has the ability
(CUPS Issue #4993) to enumerate queues and printers in print dialogs and
to auto-create a temporary print queue. This is used by applications
having the Qt dialog and printing from the command line, although the
GTK dialog still does its own thing.

cups-browsed is installed by default because cups-daemon (quite rightly)
recommends it. With the changed situation in CUPS and applications it
would appear that cups-browsed has less relevance with regard to printer
and print queue discovery and management. The Recommends field lists
packages that would be found with the cups package because there is a
strong dependency between it and cups-browsed. cups-browsed would still
enhance cups if changed to a Suggests:.

The installation of cups-browsed almost as a matter of course on many
buster systems also masks bugs in CUPS and applications, as it will take
over the management of queues/printers. A small example is CUPS Issue
#5045. Another example is with okular. For me, it will not print to a
temporary queue; with a local cups-browsed queue it will. This would
probably pass unnoticed as things stand now.

The resounding silence is an indication of the quality of this report.
It was probably a naff idea. Closing.

I disagree. Although I haven't interacted on the bug, your report sparkled
some thoughts, and I had its proper handling on my "to spend some energy on
later" list. In the meantime, cups-filters started to FTBFS in unstable; a
fix was urgent and I spent the minimal amount of energy to solve that issue.

But demoting the cups-daemon ⇒ cups-browsed relationship from a Recommends to
a Suggests is something we should consider, and your argumentation makes sense
to me.

@Till: any opinion?

I'll argue against myself by describing how I see the GUI apps handling
printing. Apologies in advance for misinformation or misinterpretation
in the testing process.

1. cups-browsed is needed by the GTK print dialog for printing to IPP
    printers (#916267).

2. At present, Qt based apps do not print to remote print queues and
    IPP printers without cups-browsed (#911702).

3. The native print dialog of the chromium browser enumerates queues
    (with the help of CUPS) but will not print to them.

4. Only LibreOffice appears to operate in a sane way by promoting
    printing to any remote queue or IPP printer without cups-browsed.

Sending CUPS semi-naked into the world of buster doesn't look like a
good idea.


To solve all the problems with the print dialogs I have started the Common Print Dialog Backends project in 2017. If Debian adopts it we will at some time really be able to work without cups-browsed.

See

https://github.com/OpenPrinting/cpdb-libs
https://github.com/OpenPrinting/cpdb-backend-cups
https://github.com/OpenPrinting/cpdb-backend-gcp
https://github.com/OpenPrinting/cpdb-backend-file

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911340
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911342
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911345

These will centralize the communication with the print systems so that the print dialogs do not need to do this and do not need to be adapted to every change in print technology.

   Till


Reply to: