http://bugzilla.novell.com/show_bug.cgi?id=514994 User jsmeix@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=514994#c9 --- Comment #9 from Johannes Meixner <jsmeix@novell.com> 2009-09-17 05:04:31 MDT --- Regarding compatibility with older distributions and foomatic stuff: cups-drivers does not and will not have gutenprint as RPM requirement because this would be two times wrong: 1. Gutenprint does not require anything in cups-drivers to run (see the details below). 2. When a user installs cups-drivers he may not want Gutenprint and therefore there is also currently no RPM requirement in cups-drivers for "gutenprint". I assume you confuse the binary RPMs which can be installed on the end-user's system with the source RPMs where the latter match to our package sources. I talk about to spilt the sources for Gutenprint from the cups-drivers package sources. The binary RPMs are already split. Gutenprint does not need Foomatic if CUPS is used, see the README file in the Gutenprint sources: --------------------------------------------------------------- .. use either CUPS or, if they use another printing system or no spooler at all, use Foomatic with the Ghostscript driver --------------------------------------------------------------- Neither Foomatic (i.e. "/usr/bin/foomatic-rip") nor the Gutenprint Ghostscript IJS driver "/usr/bin/ijsgutenprint..." is needed by Gutenprint when CUPS is used because Gutenprint provides the native CUPS driver "rastertogutenprint" (and its companion "commandtoepson"). Neither do we need any kind of Gutenprint Foomatic data because none of our printer setup tools uses Foomatic data but all our printer setup tools use PPD file information (basically what "/usr/sbin/lpinfo -l -m | head" outputs) in compliance how printer setup is done with CUPS, compare http://en.opensuse.org/YaST/Development/Printer_Enhancement "How to set up a print queue in full compliance with CUPS" For printing with the Gutenprint driver we only need the native CUPS driver and the matching CUPS PPD files. Additionally we provide Gutenprint's GIMP plug-in in the sub-package gutenprint-gimpplugin to avoid that the plain printer driver package gutenprint has RPM requirements for tons of graphical stuff (e.g. libX11 and so on) because a printer driver must be installable on a server system without X11. Regarding CUPS PPD files: PPD files can be either provided as readymade files or (since CUPS 1.2, i.e. since openSUSE 10.2) a so called "driver" in /usr/lib/cups/driver can generate PPDs during runtime ("dynamic PPDs"). Gutenprint supports both, readymade PPD files which are made during compile time and/or generating them on the end-user's system during runtime via /usr/lib/cups/driver/gutenprint. I prefer readymade PPD files because this moves the responsibility for PPD files to our build system so that there is one possible cause of issues/bugs less on the various end-user's systems. With nowadays disk space I do not care about many readymade PPD files which are installed by default. If there is limited disk space, the admin is free to simply remove any PPD in /usr/share/cups/model/ which he does not need. If someone really wants to discuss about this, he should first of all care about wasted disk space by nowadays graphical applications ;-) FYI: An advantage of generating PPDs on the end-user's system would be when /usr/lib/cups/driver/gutenprint would query attached printers for their actual capabilities (e.g. query whether or not there is actually a duplex unit and whether or not there are which additional paper trays) and then generate a PPD which contains not all theoretically possible options for this printer model but only those options and choices which match exactly to the actually connected printer. The disadvantage of this is that when e.g. a duplex unit will be mounted later, the PPD would not contain an option to use the duplex unit so that the print queue would have to be set up anew with a new generated PPD which contains the option to use the duplex unit. We also do not need any Foomatic PPDs for the Gutenprint driver i.e. PPDs where not the native CUPS driver "rastertogutenprint" is used but Gutenprint's Ghostscript driver via Foomatic's "foomatic-rip" via an entry like this in the PPD ---------------------------------------------------------------- *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip" ---------------------------------------------------------------- where "foomatic-rip" calls Gutenprint's Ghostscript driver /usr/bin/ijsgutenprint via Ghostscript's IJS interface. For backward compatibility with older distributions and of for backward compatibility with already installes systems we may try to keep (if possible) /usr/bin/ijsgutenprint in the gutenprint package so that old existing print queues with a PPD in /etc/cups/ppd/ which uses this driver might still work. On the other hand the README file in the Gutenprint sources reads: ------------------------------------------------------------------- If you attempt to use a version of Gutenprint with PPD files not built for that precise version, the driver will fail ------------------------------------------------------------------- so that existing print queues must be re-setup in any case (or the special tool "...genppdupdate..." can be used but I wonder what is easier for a normal user in the end). Therefore I think it is best to provide no longer any Foomatic-related stuff in the gutenprint package (in particular no longer /usr/bin/ijsgutenprint). On my openSUSE 11.1 workstation I do not find "ijsgutenprint" in any of the PPDs in /usr/share/cups/model/ so that the whole issue seems to have already vanished. To see which of the PPDs in /usr/share/cups/model/ use whatever IJS Ghostscript driver, run find /usr/share/cups/model/ | xargs zgrep -l -- '-sDEVICE=ijs' (only the "hpijs" PPDs should use a IJS Ghostscript driver). When Gutenprint is in its own separated package, we can remove all Gutenprint stuff from the cups-drivers package which cleans up the cups-drivers package. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.