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.

Regards,

Brian.

eOn Mon 10 Sep 2018 at 15:16:44 +0100, Brian Potkin wrote:

Enumeration of queues/printers in GTK apps depends neither on CUPS nor
cups-browsed. A user printing only from GTK apps gains nothing in basic
printing terms from cups-browsed, even if the cups service is operative.
isn't on the system; I cannot do these fundamental and useful things.

"fundamental" and "useful" are arguable, of course, but the ability
of cups-browsed to alter what a GTK app shows would be under the
heading of "Enhances".
the end of the freeze. Give CUPS a better chance to show what it is
capable of without cups-browsed. Return cups-browsed to a Recommends:
before the freeze end if it is indicated. As it stands at present, CUPS
is crippled.

I suppose a major consideration for Debian 10 is to consider what
harm not having cups-browsed as a Recommends: does; it is basically
a printer setup utility like s.c.p. Nobody gets upset when that is
not automatically on the system.

Regards,

Brian.

From

https://www.debian.org/doc/debian-policy/ch-relationships.html

  > Recommends

  >     This declares a strong, but not absolute, dependency.
  >
  >     The Recommends field should list packages that would be found
  >     together with this one in all but unusual installations

Upstream says at

http://ftp.pwg.org/pub/pwg/liaison/openprinting/minutes/OP-Minutes-20170606.htm

  > - cups-browsed development will continue, as an add-on for more sophisticated configurations, especially in enterprise networks.

  > - cups-browsed will provide the following enhancements against a pure CUPS/print dialog setup:
  >   o Legacy CUPS server (1.5.x and older) interoperability
  >   o Interoperability with old print dialogs (which do not use cupsEnumDests() and new CUPS API)
  >   o Load balancing of clustered remote CUPS queues
  >   o Support for legacy (IPP 1.x) IPP network printers
  >   o Support for new driverless printing technologies not yet supported by CUPS (like PCLm)
  >   o Fine-grained filtering of which remote printers are available

I'd suggest the first four objectives do not promote cups-browsed being
a strong dependency. The last one appears to be unworkable with QT apps
and Libreoffice.

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

Le dimanche, 21 octobre 2018, 21.21:13 h CEST Debian BTS a écrit :

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?

Cheers,
    OdyX

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.

Regards,

Brian.

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

On Thu 13 Dec 2018 at 20:04:31 +0100, Till Kamppeter wrote:

[...]

A CPD certainly looks like a good way forward. Meanwhile, I'll record
what I observe as the present situation with print dialogs using
GTK3 (libgtk-3-0), Qt (libqt5printsupport5 ) and LibreOffice.

Firefox 102.1.0esr
------------------

1. Opening "Print using the system dialog..." sees the network printers
   enumerated.
2. Selecting an entry leads to the formation of a temporary queue and
   the appearance of printer attributes in the dialog.
3. While the dialog is open, the temporary queue is restablished every
   minute, as shown by 'lpstat -a'.
4. After printing, the temporary queue takes about a minute to disappear.
5. Verdict: 10/10.


Okular 4:22.04.3-1
------------------

1. Opening the print dialog sees the network printers enumerated.
2. Selecting an entry does not lead to the formation of a temporary
   queue.
3. Printer attributes do not appear in the dialog. Under Options/Options
   Duplex-capableprinters are not recorded as such and Print Quality is
   absent from Properties/Advanced (the tab is greyed out).
4. Print and the printer attributes become available via the formation
   of a temporary queue. But re-open the dialog within a minute to gain
   access to the queue!
5. Verdict: 1/10.


Libreoffice 1:7.4.0~rc3-1
-------------------------

1. Opening the print dialog sees the network printers enumerated.
2. Selecting an entry does not lead to the formation of a temporary
   queue.
3. Printer attributes do not appear in the dialog. Page sizes bear little
   relationship to reality, there is a pretend option for printing in
   duplex and Print Qualty is nowhere to be seen.
4. Print and the printer attributes become available via the formation
   of a temporary queue that lasts a minute. But a twist on Qt! Attributs
   are kept in memory and only disappear when Libreoffice is closed.
5. Verdict: 3/10 (for ingenuity).


That's on Debian. Maybe things are different elsewhere.

Cheers,

Brian.

With the recent vulnerability in cups-browsed, it may be a good idea to
revisit this subject?