Hello,
the last few days I have been trying to set up Debian packaging for a bigger project which should have multiple binary packages. I have been using Ubuntu 21.04 Hirsute as my test platform and the latest release 0.6.1 of the dh-cmake project.
To get up to speed and familiar, I have been playing with the examples in the examples folder, mainly the cmake and cpack ones. And to be truthful, it was not a nice journey. I discovered that when you have errors in the build recipes, the Debian workflow does not error out, but just acts weird.
Thus, I am not sure if this is a bug, or I am just doing something wrong, and I would like for somebody to confirm or refute (using the cpack example): When your control file have only one Package, the build will ignore the package_name.cpack-components specification of components and will include everything which was installed into debian/tmp. The moment you add a second Package - even an empty one - everything will start to work as expected and non-specified components will not be copied from debian/tmp to any package.
dh-cmake maintainer here. When I was developing dh-cmake and reading about Debhelper, I’d gotten the impression that if there was only one binary package, Debhelper programs could skip the package_name and look for a file with only the extension. Is that not the case?
If you have a specific use case that’s not working the way you expect, please file a Debian bug (dh-cmake is a proper Debian package) with the repro, and I will take a look.
That’s the thing. I don’t know, my main objective is to just create packages, I am nowhere near knowledgeable enough about Debian’s policies to say one way or another. But by instinct, when I specify a component or group to install to a package, I expect it to install just that one component or group, not everything defined in install().
If you say it is intentional, fine - but on the same page I think that it should be directly documented, maybe as an example or comment.
I was able to get it to create packages during the native build. It took me more time than I would like, but I got there.
I do think that the dh-cmake package should be hinted as a Multi-Arch: foreign, because the mk-build-deps -a<architrecture> has problem installing it when cross-compiling.
Specifically, adding this line. Tested with this package and standard dh-cmake, dh-cmake-compat (= 1), dh-sequence-cpack in debian/control, everything builds fine with dpkg-buildpackage -us -uc -b -a<architecture>.
Now that I think about it, this may actually be because of Debhelper proper, rather than dh-cmake. If there’s only one binary package, Debhelper installs everything into debian/tmp, which gets included in the single binary package.
I am trying to package my existing cmake project with nsis(windows) ,deb(ubuntu), and osx.
Searches led me to dh-cmake,but I just do not get it.
The examples do not have the CPACK deb variables i would expect. Is this not compatible with calling cpack and needs to be called from dpkg instead. How does it even know about files in the debian directory.
I have a service to install and enable (or disable-remove/disable-update-enable) that is systemd flavour. There is a optional component for developers with symbols and a web console for debugging.
dh-cmake was created specifically for packaging CMake-based projects in Debian proper, because the CPack .deb generator inherently does not conform to the Debian standards. If you just want to generate a .deb, just use CPack’s .deb generator.
Sorry if I am not fully understanding “in debian proper”
Does this mean it is a different workflow? Maybe calling a debian command that references the cmake project and not calling cpack? I mean, I did not even see where CPACK is told the generator is deb.
I still need postinstall and such scripts to install and enable the service and can just do that with a .in file.
I am just trying to do it the proper way for 2023, whatever that is.
Yes, it’s a different workflow. Packages that are shipped natively with Debian use a build process that is incompatible with CMake’s .deb generator. dh-cmake was made to take advantage of CPack’s component graph while still conforming to the standards required to build packages that Debian ships natively.
In your case you almost certainly want to use CPack’s .deb generator.
