[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging the new OpenPrinting project Common Print Dialog Backends



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



Reply to: