Differences between revisions 3 and 4
Revision 3 as of 2011-10-06 16:05:02
Size: 2783
Editor: DidierRaboud
Comment: Binary packages proposal
Revision 4 as of 2011-10-06 16:24:10
Size: 4571
Editor: DidierRaboud
Comment:
Deletions are marked like this. Additions are marked like this.
Line 43: Line 43:
   * To be discussed: Shall we give those `Provides: printer-driver`, alike is done for `xserver-xorg-video-*` packages?
   * To be discussed: Shall we create one `printer-driver-all`, `Depend`ing on all printer drivers, alike is done for `xserver-xorg-video-all`? Then each package needing ''any'' printer driver would simply `Depend` on `printer-driver-all | printer-driver` (think about providing a "dummy-empty" `printer-driver-dummy` as e.g. Cups can print to some printers without any driver.
Line 48: Line 50:
As an image can be worth thousand words:

{{attachment:printing-graph_20111006_50.png|A graph with the current dependencies within the printing stack|width=100%}}

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

Something (to be discussed) should be done about this.
Line 49: Line 59:

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 [[DebianPts:foo2zjs]] is a direct dependency of it, for an unknown reason; same goes for hp-ppd.

== Action proposal ==

Iff binary package renames and a big refactoring of the inter-relations inbetween 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;
 1. Alter packages, create new binaries, upload to Debian experimental, trough the NEW queue;
 1. Test global upgradeability from unstable to experimental once the change is well engaged;
 1. Upload as a whole to unstable in agreement with the Debian Release Team.
 1. Sync to Ubuntu precise; test upgreadability from oneiric and from past LTS.
 1. Then, if possible, do any change in Debian unstable and sync to (or back) to Ubuntu.

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:

  • dh_pyppd compresses PPDs to a CUPS-specific directory ( /usr/lib/cups/driver ), which obfuscates the availability of those PPDs to users of other print server users.

    • Proposal: Compress to /usr/share/ppd/compressed/ instead, with a symlink to /usr/lib/cups/driver.

Package naming inconsistencies

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

Current inconsistencies:

  • There is currently no printing drivers naming policy. Printer driver binary packages names carry no consistent link back to the printers they drive.
    • As examples:
      • foo2zjs enables FLOSS-printing to some HP printers

      • epson-escpr enables printing to Epson Inkjet printers

      • rastertosag-gdi enables printing to Ricoh Aficio SP110* printers

    • Proposal: Rename binary packages to printer-driver-${Corp}-${Model}, whatever the technology (ZJS for foo2zjs, SAG-GDI for rastertosag-gdi, …) is.

      • To be discussed: Shall we keep transitional packages or are Replaces/Breaks/Provides sufficient ?
      • To be discussed: Shall we give those Provides: printer-driver, alike is done for xserver-xorg-video-* packages?

      • To be discussed: Shall we create one printer-driver-all, Depending on all printer drivers, alike is done for xserver-xorg-video-all? Then each package needing any printer driver would simply Depend on printer-driver-all | printer-driver (think about providing a "dummy-empty" printer-driver-dummy as e.g. Cups can print to some printers without any driver.

    • Proposal²: Rename source packages too (not sure what the benefit is though)

      • To be noted: this breaks BTS tracking and mandates a reassign for all current (and past?) bugs.

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.

Action proposal

Iff binary package renames and a big refactoring of the inter-relations inbetween 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 experimental, trough the NEW queue;
  3. Test global upgradeability from unstable to experimental once the change is well engaged;
  4. Upload as a whole to unstable in agreement with the Debian Release Team.
  5. Sync to Ubuntu precise; test upgreadability from oneiric and from past LTS.
  6. Then, if possible, do any change in Debian unstable and sync to (or back) to Ubuntu.