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

Re: Printing packaging rework 2020





On 30/01/2020 16:48, Didier 'OdyX' Raboud wrote:
Dear Till and Brian,

(I'm currently at pre-FOSDEM miniDebConf in Brussels, if any of you is around,
let's chat!)

With the blessing of driverless printing, it seems we're now in a world where
most (%-age ?) printers sold in the last (how many?) years support driverless
printing. Support is not perfect everywhere, but we've come such a long way
that, with a recent printer, on a normal network, it just "pops" in CUPS and
its interfaces, and printing "works", in mere seconds.


General use network printers seem indeed all be driverless, even cheap models, simply because manufacturers want to allow people print from their phones.

Printer needing drivers are more the specialty printers, like label printers for example, and here Mike Sweet did a good start with a Printer Application, which you have debianized now.

In general, printer drivers are supposed to be provided as Printer Applications from now on. I will do some Printer Applications for legacy printer drivers for Ubuntu in the next weeks, to be made available as snaps in the Snap store.

But the Debian packaging (task-print-server, cups, …) still installs _a lot_
of printer drivers and other related packages. Although in the past I was
convinced we needed to make sure that _all_ printer drivers should be
installed everywhere (hence the creation and usage of the printer-driver-all
meta-package), I'm getting more and more convinced that we should reverse this
course and install "just" what's needed to print driverless to a network
printer in "most" cases.

I have started laying down my plan on the Debian Wiki:
	https://wiki.debian.org/Teams/Printing/2020DriverlessByDefault

I'd love to get input from you to know if:
a) that's something desireable;
b) the way I thought of it makes sense;


I think it is a good idea to get rid of the loads of printer drivers. Most of them are for decades-old printers. The few people who have saved their printers through such a long time could install the packages if needed.

We need to ask some driver developers who maintain their drivers until now (HPLIP, Gutenprint, Ricoh PPDs, ...) whether there are relevant new models which need a driver or where printing with driver is highly recommended. Perhaps we ship only these driver packages by default then.

For the default config of cupsd, you suggest two versions: One only listening on the socket and therefore not sharing printers and not providing the web admin interface. Makes sense for desktops which are not sharing printers, they even do not need to share printers if all the available printers are network printers, and administration is done by a GUI app like GNOME Control Center or system-config-printer. The other alternative is to also listen on localhost:631 which opens up printer sharing and the web interface, the recommended way for a headless server, as print queues are only there for sharing and one wants to do remote administration, so the web interface gets useful.

You are giving names to the two default config alternatves. "cups-daemon-headless" I would give to the server config which shares printers and uses the web interface. This is how to use CUPS on headless (no monitor and keyboard) servers. The other one, only listening on the domain socket is not for headless servers but for desktops.

AFAIR one can switch between these scenarios with cupsctl or the "Server Settings" in system-config-printer.

I do not know how we could in .deb packages make a server installation default to one and a desktop installation to the other.

We will need a running cups-browsed as long as print dialogs do not reliably display CUPS' temporary queues. As soon as they do so, cups-browsed is only needed for more sophisticated network printing configurations.

What are your thoughts there? Do the work directly in experimental, and
iterate until it's satisfactory?


Probably we should try it out in Experimental. That's a good idea.

   Till


Reply to: