print/cups-filters, print/libcupsfilters and print/libppd

Edgar Fuß <[email protected]> Wed, 29 Jul 2026 12:44:53 +0200
Newsgroups gmane.os.netbsd.devel.packages
Message-ID <[email protected]>
Does someone with CUPS knowledge understand the relationship between the 
cups-filters, libcupsfilters and libppd packages?
Both somehow use (or don't use) renderers like poppler, ghostscript and 
mutools and seem to have some (optional?) use of dbus for colour management.

I added options originally to cupsfilters, then, as some part seems to have 
been factored out into libppd, there, to select which (in my use case, 
PDF-to-PS) renderers to include and set CUPS' default PDF-to-PS-renderer; 
I also have -dbus in PKG_DEFAULT_OPTIONS since I only use those packages 
on a server.

I (and apperantly, others before) additionally seem to have got confused by 
cups-filters having been split out of cups-browsed (which, itself, seems to 
be completely useless now it can't send any kind of browse messages anymore), 
and mistakenly removed dbus from cups-filters, not realizing it was used 
for colour management.

Can someone in the know shed some light on this? I know my questions are 
mostly questions about upstream's infinite wisdom, but maybe someone did 
already dig through this.

I.e.:
-- why did upstream factor out libcupsfilters?
-- why did upstream factor out libppd?
-- why does upstream think it's libppd's job to render PDF to PS?
-- whould it make sense to add options to cups-filters to select renderers?
-- is it possible to build all this bunch of packages without dbus?