On 27/03/2024 16:22, Michael Weghorn wrote:
Are you aware of any specific reasons why distros would prefer direct use of
CUPS API over CPDB other than the usual packaging efforts needed for any new
library?
No.
It could only happen that some distros are perhaps not aware of CPDB and
therefore try to go the way of directly talking with CUPs.
Even better if the approach other projects take seems to be the same one as
we're discussing for LibreOffice now. This should also provide a more uniform
user experience (same printers + options show up regardless of the
application/toolkit,...).
Yes, if all use CPDB, options will look the same everywhere. And a cloud
printing service could be made available in all print dialogs by installing a
single CPDB backend.
There's the existing [1], but I don't know whether that would still be the right
place to report such things these days.
We do not use the Linux Foundation Bugzilla any more. All our projects are on
GitHub already for several years and we use the issue trackers of GitHub.
That sounds reasonable and shouldn't be a problem in general, but will of course
need a closer look into the code to see whether CUPS-related code is already
fairly local or currently spread all over the place right now, requiring some
more refactoring or reconsideration.
OK. If CPDB is used it must be taken care that we nowhere talk with CUPS
directly, as otherwise non-CUPS CPDB backends (cloud printing services) will not
work.
We already have various `--enable-<feature>`/`--disable-<feature>` configure
flags (some with autodetection if not passed explicitly) for various features.
Adding additional ones for those cases should be fine and fairly straightforward.
The usual stuff of most projects: ./configure auto-detects presence of libraries
and in addition have command line options for manual selection. So one can
easily opt for CPDB (or it gets even auto-selected) when one wants to support
CUPS 3.x.
(Details on how to configure things at build and run time can also be discussed
later.)
OK.
Till
