[cmake][multipackaging] best practices
Hi,
Recently I pushed a couple of changes to the cmake project that allow
cmake to run on Launchpad. Those changes were targeted at making cmake
able to create Debian packages directly (before that, it was unable to
create Debian packages in fakeroot, and packages definitions were too
rough).
I am now able to package my project properly in Launchpad, without going
through any install step. My source code produces several .deb files,
and all of them is managed by cmake directly because I want the split of
the project be done in all platforms the same way.
I have some open questions and doubts about how I implemented this, and
I wanted to have feedbacks on the debian/rule and debian/control file I
wrote. Also I am not sure if those are correct wrt. the packages created
by cmake (will explain below).
As I said, the rationale behind those changes is to be able to create
packages from cmake directly, such that the packages definitions is
maintained at the cmake level on all platforms.
The PPA is here for those interested:
https://code.launchpad.net/~raffi-enficiaud-x/+archive/ubuntu/yayi
The package control file is located there:
https://bitbucket.org/renficiaud/yayi-debian-ppa/src/572104f84c745b61d04473912e0bc3f47c0dde6f/debian/control?at=master&fileviewer=file-view-default
- it contains one source package, "yayi" and 5 binary packages
- some of the fields such as "description", "depends" are not the same
as the ones defined in the cmake project. On Launchpad, the descriptions
and dependencies are those set by cmake during the .deb packages
generation.
The package rule file is located there:
https://bitbucket.org/renficiaud/yayi-debian-ppa/src/572104f84c745b61d04473912e0bc3f47c0dde6f/debian/rules?at=master&fileviewer=file-view-default
- the "build-arch" target configures and builds the project. It passes
the version of the package (extracted from "dpkg-parsechangelog") to the
configuration in order to have the proper intra-binary package
dependencies (eg. "yayi-python" depends on "yayi-core" with exact
version match).
- the "binary-arch" target creates the packages using "cpack" directly,
but it does a couple of more things:
- it corrects for the generated file names using "dpkg-name"
- it adds the files generated from cmake to the additional files
using dpkg-distaddfile
Everything is done out of the source tree, and there is no "make
install" step. I also do not need to specify which file to include in
which .deb, as it is done already in the cmake scripts.
Now the questions are the following:
- I had the add a patch to cmake (currently in my PPA) in order to
reference the source package from the binary ones. This defines a
DEBIAN/control with a source field (pointing to "yayi") for every
packages, without any version. Is that the correct way? (before I do
that, the generated .deb were rejected by Launchpad). Should the version
match?
- The project itself uses the git version of the repository, discovered
by cmake, and generates a file (in source) containing the
version/revision it has been built from and that is being compiled. Now
I simply patch this file. The problem with the current approaches is
that there are 2: one revision managed by the package manager, another
one in the source code, and obviously there may be a mismatch. What is
the correct way of transferring an exact repository revision to the
generated source file? Is that something we want in general, or should
this information be included in the package only? In my previous work, I
found quite useful to query the program for the exact revision it has
been built from (and not the package manager).
- the generated .deb are placed on the top directory, their name gets
corrected according to the revision, using "dpkg-name", and I signal the
generated files in debian/files using "dpkg-distaddfile". Is it correct?
Basically, I would like to have cmake generating all the .deb files, but
in the best way with the debian tools. Some information are redundant
(description of the packages for instance, or dependencies, etc) between
those two systems. The only thing I would like the debian/control file
to contain is the name of the source package, and maybe the binary
packages. If the content of the .deb does not match fully the one in the
debian/control, is one taking precedence over the other?
I do not know if "dh" can do a "cpack -G DEB" (with potential additional
parameters such as the revision). I also do not know if there is an
automatic variable that indicates the revision in the debian/rule, or
the package being built (which then can be handled with "cmake
-DCOMPONENT=`component_name` -P cmake_install.cmake").
I would be happy if all those can be done in "dh" directly, but as far
as I understood, "dh" handles the cmake configuration and the "make" +
"make install" step, and then passes the installed files to debian
tools. I would like "dh" to configure, make and ask cmake to generate
the packages directly (without any "make install").
Thanks,
Raffi Enficiaud
PS: I already had a look (from previous posts) to
http://sources.debian.net/src/blender/2.76%2Bdfsg0-1/ ,
http://anonscm.debian.org/gitweb/?p=collab-maint/kwstyle.git;a=blob;f=debian/rules;h=2e854096a086a53312ec488891a5f75e2d5294d2;hb=HEAD
,
http://php-java-bridge.cvs.sourceforge.net/viewvc/php-java-bridge/php-java-bridge/debian/
and https://wiki.debian.org/PkgSplit
Reply to: