+++ Raffi Enficiaud [2015-11-02 11:04 +0100]: > Hi, > > 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. Hmm. interesting idea. For reasonably 'standard' packages this may actually make some sense. But as others have pointed out there are also real difficulties in not using the standard debian ecosystem tools. Try hard to make sure the defined interfaces (debian/rules targets) work the same. If you want to make cmake work better with debian packages, I suggest that the most pressing issue is the multiarch support. If you are someone that understands cmake I would like to work with you on making multiarch 'just work' for packagers. There is some support in cmake already, but I admit that I do not really understand how it is supposed to work, and in practice it quite often doesn't seem to work. There is also zero documentation I have been able to find. There are also issues with cmake and cross-compiling it would be good to get to the bottom of (again it works in some packages as epected, but not in others. Are you interested in discussing this stuff? It may be that the cmake support is fine and we just need to document how to use it, but I suspect that there things that could be improved that minimised the amount of extra boilerplate in each cmake package's rules file. > 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. This works so long as the debian packages look the same as other platforms, but sometimes there will be differences (extra files, changed files). There needs to be some exception/additional rules mechanism, I suspect. > 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 source package version normally matches the binary package version, but not always. They can be defined to be different (and sometimes are - see the cross-binutils package for an example). The binary package should always refernce the source package (with version) from which it was built. > - 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). You need to think carefully about versioning. A debian binary came from a specific revision of debian source. The debian source comes from a specific upstream (git in this case) version. > - 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? I don't know. Can you give a specific example? > 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? Good question. Probably some tools will get confused if things don't match up, or packages might get rejected, depending on what is wrong. > 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"). dh can have a '--with cmake' if you write a dh-cmake package. Possibly this would be the right way to integrate things better. But completely taking over the install step is quite radical. You would need to show that it didn't actually break anything to get it accepted. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: Digital signature