Rethinking the Printing Stack for Wheezy / Precise

Now that most printing packages are under few team umbrellas; now that both Ubuntu and Debian will both be unfrozen for some period, it's clearly a good time to take a step back and look at the big picture.

(Note that this is obviously partial and that everything here should be subject to discussion.)

Overall goal

Whatever the issues might be, there is certainly a set of common goals we should agree on:

  1. the "print-server" tasksel task should install CUPS and all printer drivers (with Recommends to be able to remove them afterwards)
  2. there should be very few "printing" top-level packages, that all install:
    • one print server (CUPS, lpd, …)
    • the printers database (foomatic-db{,-compressed})
    • all printer drivers.
  3. at each level of the stack, the binary packages should be named coherently and dependencies between and within the levels should be coherent and logical.
  4. it should be possible to sanely move from one print server to another without needing to uninstall the whole stack of databases and printing drivers.

Issues and proposed solutions

CUPS-specificity

As far as I can tell, Ubuntu only has CUPS as available print server, so it's clearly more a challenge for Debian.

Current specificities:

Package naming inconsistencies

Many printing-related packages are not named consistently; in particular drivers.

Current inconsistencies:

Dependencies mess

As an image can be worth thousand words:

A graph with the current dependencies within the printing stack

Depends are blue, Recommends are black and Suggests are gray.

Something (to be discussed) should be done about this.

Lack of clear entry-point

Currently, when one wants a "working printing stack", there is no clear "root" package that provides that. If one takes a look at the print-server task, then foo2zjs is a direct dependency of it, for an unknown reason; same goes for hp-ppd.

Other

Where does PpdFileStructureSpecification fit in this discussion? Does it need revision, or removal?

Action proposal

Iff binary package renames and a big refactoring of the inter-relations in-between the various packages are both agreed on, the sanest plan would be:

  1. Agree on a plan common to Debian, Ubuntu and whatever other derivatives would like to take part of the discussion;
  2. Alter packages, create new binaries, upload to Debian unstable, trough the NEW queue;
  3. Test global upgradeability from previous releases to unstable frequently enough;
  4. Sync to Ubuntu precise; test upgreadability from oneiric and from past LTS.
  5. Then, if possible, do any change in Debian unstable and sync to (or back) to Ubuntu.

Action 1 - Rename printing driver packages

Status: Implemented, besides out-of-team packages

Rename binary packages to printer-driver-${Identifier}.

Details

Package renames

Old binary package name

New binary package name

Comment

Status

c2050

printer-driver-c2050

Done.

c2esp

printer-driver-c2esp

Done.

cjet

printer-driver-cjet

Not under Team's umbrella

Renaming asked: 647531

epson-escpr

printer-driver-escpr

Done.

foo2zjs

printer-driver-foo2zjs

Done.

m2300w

printer-driver-m2300w

Done.

ptouch-driver

printer-driver-ptouch

Done.

pxljr

printer-driver-pxljr

Done.

splix

printer-driver-splix

Not under Team's umbrella

Done trough: 647534

min12xww

printer-driver-min12xww

Not under Team's umbrella

Done trough: 647538

pnm2ppa

printer-driver-pnm2ppa

Done.

rastertosag-gdi

printer-driver-sag-gdi

Done.