Re: cups-filters 1.0.44 and binary package splitting for mobile
On 01/19/2014 01:58 PM, Didier 'OdyX' Raboud wrote:
> Reviewing the package before uploading made me aware of a new question:
> shouldn't cups-filters-core-drivers depend (or at the very least
> recommend) on ghostscript ? At least:
>
> a) pdftoippprinter tries to use either gstoraster filter (in cups-
> filters) or ghostscript through CUPS_GHOSTSCRIPT, then fallbacks to
> pdftoraster.
> b) pdftops tries to use gs through CUPS_GHOSTSCRIPT if pdftops-renderer
> is configured that way (which is default as far as I could see).
>
> So for b) at least, cups-filters-core-drivers needs to depend on
> ghostscript, which is apparently conflicting with the goal of having a
> small-footprint package. The other possibility is to configure cups-
> filters with --with-pdftops=hybrid, no?
This is not needed, pdftoippprinter leads with Poppler-only (and also
Ghostscript-only) systems independent of default configuration. It
always checks presence of Poppler components (/usr/bin/pdftops,
pdftoraster, CUPS_POPPLER_PDFTOPS) and of Ghostscript components (gs,
gstoraster, gstopxl, CUPS_GHOSTSCRIPT) before using them. It also adds
"pdftops-renderer=..." to the filter command line if the absense of a
renderer requires the use of the other, overriding any default settings.
So a Poppler-only system (typical situation for a phone) will work
perfectly, independent of the --with-pdftops=... default choice done at
build time (so we use the most desktop-friendly "hybrid" here).
So do not add Depends/Recommends or use OR ("|") relationships which get
fulfilled also if the system is Poppler-only or Ghostscript-only.
Till
Reply to: