Hi,
I have continued work on cpdb-libs. I hope someone can help me here and
tell whether I have done the Debian packaging correctly.
First I have re-organized the upstream code:
I have looked through the code of the libraries to see whether I could
do the separation of the common library code into a third
libcpdb-libs-common library. Now I have found out that there is much
more common code according to lib/Makefile.am.
There are 4 C files in lib:
- backend_interface.c
- frontend_interface.c
- frontend_helper.c
- common_helper.c
Looking into lib/Makefile.am The frontend library libcpdb_libs_frontend
is linked together from all these files, the backend library from all
except the frontend_helper.
So to make a set of libraries without code duplication there would be a
common library containing the code of backend_interface.c,
frontend_interface.c, and common_helper.c and a frontend library
depending on the common library which only contains frontend_helper.c.
There would be no backend library. Backends would only use the common
library.
In general, the code duplication is not such a big problem as we have
only small libraries (70 kb max.) and the duplicated code comes from the
same source package, meaning that on a security update in a distribution
both frontend and backend libraries get updated and never only one of
the two, as on an update always a source package gets replaced and by
that all binary packages generated from the source package, never an
individual binary package.
Disadvantage of this change is that with a correct avoidance of code
duplication we end up with a common library and a frontend library
instead of a frontend library and a backend library, making our package
incompatible with existing code of backends and dialogs.
Separating only the code of common_helper.c into its own library would
only help for the symmetry, having a library corresponding to
common_helper.h.
So I have made a common library libcpdb-libs-common
(backend_interface.c, frontend_interface.c, and common_helper.c) and a
frontend library libcpdb-libs-frontemd (frontend_helper.c) now and three
pkgconfig *.pc files, where one uses cpdb-libs-backend.pc if one wants
to make a backend package and cpdb-libs-frontend.pc for a frontend
package. The common library then gets pulled in by dependencies.
This I have released as upstream version 1.1.0 of cpdb-libs.
For the Debianization I have put the files into binary packages as follows:
libcpdb-libs-common0:
The common library libcpdb-libs-common
libcpdb-libs-frontend0:
The frontend library libcpdb-libs-frontend
libcpdb-libs-common-dev:
The static common library
The headers of the code in the common library:
/usr/include/cpd-interface-headers/common_helper.h
/usr/include/cpd-interface-headers/backend_interface.h
/usr/include/cpd-interface-headers/frontend_interface.h
The common pkgconfig file:
/usr/lib/*/pkgconfig/cpdb-libs-common.pc
libcpdb-libs-frontend-dev:
The static frontend library
The headers of the code in the frontend library:
/usr/include/cpd-interface-headers/frontend_helper.h
The pkgconfig file for the frontends:
/usr/lib/*/pkgconfig/cpdb-libs-frontend.pc
The meta header file to include all frontend-relevant headers:
/usr/include/cpdb-libs-frontend.h
libcpdb-libs-backend-dev:
The pkgconfig file for the backends:
/usr/lib/*/pkgconfig/cpdb-libs-backend.pc
The meta header file to include all backend-relevant headers:
/usr/include/cpdb-libs-backend.h
Note that there is no libcpdb-libs-backend0 package as there is no
library code needed only in backends. libcpdb-libs-backend-dev is more
or less a meta package where print dialog backend packages can
build-depend on and automatically pull in everything needed by
dependencies. A libcpdb-libs-backend0 can get added later on should
upstream introduce a
libcpdb-libs-backend library with backend-specific functions.
So we have symmetry here:
If you want to package a print dialog (frontend for Common Print Dialog
Backends interface) you build depend on libcpdb-libs-frontend-dev.
If you want to package a Common Print Dialog backend using this
interface, you build-depend on libcpdb-libs-backend-dev.
The Debian source package can get downloaded here for trying out:
http://www.openprinting.org/download/tmp/cpdb-libs_1.1.0-0ubuntu1.dsc
http://www.openprinting.org/download/tmp/cpdb-libs_1.1.0.orig.tar.gz
http://www.openprinting.org/download/tmp/cpdb-libs_1.1.0-0ubuntu1.debian.tar.xz
Can someone have a look at the packaging and tell me whether it is OK
for getting into Debian? Thanks.
Till
On 11/28/2017 10:00 PM, Till Kamppeter wrote:
Hi,
I hope someone has read my posting from one month ago, cited below.
I have looked into how to package cpdb-libs and asked Nilanjana (the
student who wrote this package) for some changes but she did not come
around to do them. So I packaged the current GIT snapshot now.
The source package is downloadable here, so that you can have a look:
http://www.openprinting.org/download/tmp/cpdb-libs_1.0+20171128-0ubuntu1.debian.tar.xz
http://www.openprinting.org/download/tmp/cpdb-libs_1.0+20171128-0ubuntu1.dsc
http://www.openprinting.org/download/tmp/cpdb-libs_1.0+20171128.orig.tar.gz
It works all well, but it has a little oddity: The source package
provides two shared library, one named libcpdb-libs-backend, to be used
by the print dialog backends and one named libcpdb-libs-frontend, to be
used by the print dialogs. Under the binary packages generated are two
packages providing the libraries and the two appropriate -dev packages.
The two libraries also contain some helper functions in common, from
lib/common_helper.c and described in the header common_helper.h. As
these functions are linked into both libraries one would have to put
common_helper.h into both -dev packages, but this would make them
conflicting. Therefore I have created an additional
libcpdb-libs-common-dev binary package and made the -dev pakages of both
libraries depending on this one.
Is this OK? Or have I to proceed in another way for this?
Till
On 10/27/2017 01:58 PM, Till Kamppeter wrote:
Hi,
as you perhaps know we have started a new project in this year's
Google Summer of Code. Five students have worked on a new concept to
assure feature completeness, printing technology support, and
maintainability of print dialogs.
A problem of desktop printing is that there are many different print
dialogs, from different GUI toolkits like GTK and Qt but also from
individual applications like LibreOffice or the Chromium Browser.
Adding new print technologies (like Google Cloud Print) or new
features to existing print technologies (like CUPS' new feature of
auto-creating temporary queues for driverless IPP printers) always
require changes on the print dialogs and due to the fact that they are
often not well maintained and that the GUI toolkits have rather long
release cycles the new technologies and features do not get supported
by the print dialogs of desktop apps.
To overcome this we have introduced a concept of separating the print
dialog's GUIs from the print dialog's communication with the printing
systems using a frontend/backend concept with a D-Bus interface.
For each print technology (currently CUPS/IPP and Google Cloud Print,
soon also save to PDF file) there is a GUI-toolkit-independent backend
doing the communication with the printing system and providing a D-Bus
API to the frontends (the print dialogs). A print dialog, when it is
opened, first does a broadcast call into the D-Bus to find which
backends are installed, then calls the list-printers function of each
backend to get a list of all available printers. When the user selects
a printer, the appropriate backend is asked for further capabilities
of the printer (to build the printer options screen) and if the
"Print" buttonis clicked, the PDF is sent to the selected printer via
its backend.
To get it into Debian (and from there into Ubuntu) at first the
GUI-toolkit independent parts needs to get packages. These are the
following projects on the new OpenPrinting GitHub
(https://github.com/OpenPrinting):
cpdb-libs:
https://github.com/OpenPrinting/cpdb-libs
Frontend and Backend Libraries
These libraries allow for easy use of the D-Bus interface by print
dialogs (frontends) and backends providing simple APIs so that the
developer does not need to do the D-Bus communication directly.
cpdb-backend-cups:
https://github.com/OpenPrinting/cpdb-backend-cups
CUPS/IPP Backend
This backend does all the communication with CUPS (and IPP printers)
for listing printers and capabilities and sending off print jobs.
Needs cpdb-libs.
cpdb-backend-gcp:
https://github.com/OpenPrinting/cpdb-backend-gcp
Google Cloud Print Backend
This backend does all the communication with Google's servers for
Cloud Print for listing printers and capabilities and sending off
print jobs. Needs cpdb-libs.
These three projects need to be Debian-packaged in three source
packages so that the GUI toolkits (GTK and Qt) and LibreOffice can get
built with this functionality. LibreOffice has already adopted these
changes to be included in their next release. GTK will have it in its
next major release. Qt will probable include it in 5.10. An adaptor
backend for using the Common Print Dialog Backends with current GTK's
print dialog is in the works.
My plans are to introduce this new concept in Ubuntu 18.04 (Feature
Freeze mid-February 2018). It would be great if the Debian packaging
could be done soon so that I can sync it into Ubuntu.
Thank you very much for any form of cooperation.
Till
