This is the numbering of the DEB package itself, i.e. the version of thepackaging and not the version of the content (seeCPACK_DEBIAN_PACKAGE_VERSION). One may change the default valueif the previous packaging was buggy and/or you want to put here a fancy Linuxdistro specific numbering.
Sets the Pre-Depends field of the Debian package.Like Depends, except that italso forces dpkg to complete installation of the packages namedbefore even starting the installation of the package which declares thepre-dependency.
Sets the Breaks field of the Debian package.When a binary package (P) declares that it breaks other packages (B),dpkg will not allow the package (P) which declares Breaks beunpacked unless the packages that will be broken (B) are deconfiguredfirst.As long as the package (P) is configured, the previously deconfiguredpackages (B) cannot be reconfigured again.
The original permissions of the files will be used in the finalpackage unless the variableCPACK_DEBIAN_PACKAGE_CONTROL_STRICT_PERMISSION is set.In particular, the scripts should have the proper executableflag prior to the generation of the package.
Sets the Source field of the binary Debian package.When the binary package name is not the same as the source package name(in particular when several components/binaries are generated from onesource) the source from which the binary has been generated should beindicated with the field Source.
I am considering to create a Debian package from an existing library (paho-mqtt-c). The project uses CMake as its build system. After some research I think I need to create two or three different packages:
I briefly looked into this and it seems to be the most modern solution and it should be possible to combine this with CPack. However, it seems dh-cmake is only available for Ubuntu 18.04 and 16.04, but I am using Ubuntu 19.10 so I was not able to install dh-cmake on my system.
And then run debuild and it will run cmake install to temporary folder and pack an installable deb package from it.To quickly create those debian files run dh_make --createorig and press s for source package.Then you'll need to carefully edit debian files as described in Chapter 4. Required files under the debian directory of Debian New Maintainers' Guide.
The dh-cmake is needed for more sophisticated things. CPack won't work for you if you want to publish to PPA because its buildbot will anyway run debhelper (short version of debuild) so it needs for the debian folder
or you could use cpack with cmake to generate a deb fairly easy to do but cmake and cpack are poorly documented still they work wellI suggest adding the following to the bottom of CMakeLists.txt
This is a stronger restriction thanBreaks, which prevents thebroken package from being configured while the breaking package is inthe "Unpacked" state but allows both packages to be unpacked at the sametime.
The original permissions of the files will be used in the finalpackage unless this variable is set to TRUE.In particular, the scripts should have the proper executableflag prior to the generation of the package.
Additionally, if CPACK_STRIP_FILES is set, the files will be stripped beforethey get to the DEB generator, so will not contain debug symbols anda dbgsym package will not get built. Do not use with CPACK_STRIP_FILES.
The environment variable SOURCE_DATE_EPOCH may be set to a UNIXtimestamp, defined as the number of seconds, excluding leap seconds,since 01 Jan 1970 00:00:00 UTC. If set, the CPack DEB generator willuse its value for timestamps in the package.
In my case I needed to make a deb package for one of the libraries of our SDK, so deb package format will be the main focus of this article. Additional complexity of the task was that I needed to make a package only for that library and not for the entire SDK.
The deb package produced by CPack above is already fine and can be installed with dpkg. However, there is a tool for running checks on packages - Lintian - and it will not be happy about that package quality:
Generate SSH key, add its public part to /home/packages/.ssh/authorized_keys on server. Create an entry in /.ssh/config on client/user machine with private key (might need to do that for root user too, because apt is likely to be called with sudo).
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.
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.
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.
There are a lot of *qt5* packages, and I've tried installing the promising looking ones to no effect. All the discussions I've found either have things working fine or are talking about writing CMake build rules rather than executing them. I don't have a lot of experience with the organization of Debian/Ubuntu packaging.
The debian package management system used not only by Debian but also by Ubuntu, Raspbian and many other Linux distributions. In addition to dependency handling and versioning packagers can use several other features, namely:
It is much more natural for a CMake-based project and you can reuse much of your metadata for other target platforms. It also shields you from a lot of the gory details of debian packaging without removing too much of the power of deb-packages.
How do you deal with this in general, I use cmake and the shared libraries come from QT and ArcGIS (ArcGIS requires a specific version of QT to work). I would prefer just supplying all the shared libs within my package so I am sure every user has the libs available.
The above error was popping up when I was trying to run debuild , but was ableto compile succesfully when was using cmake and make directly. So this is wheremy project halted for now. Hopefully will soon be able to figure out why the aboveerror is popping up while running dh_auto_install and not when compiled directly.
I decided to build the most recent version of libfmt and install it, but Iwanted to keep my new installation as clean as possible, so I checked whether Icould find a guide on how to (easily) turn a CMake build into a .deb package.
And I was surprised to find CPackand its DEB Generator.It turns out CMake has a module to automatically generate package bundles forthe code it builds! It supports producing tarballs, Qt IFW, NSIS. NuGetpackages, .rpm and .deb packages, which is just what I was looking for.
When I ran CMake, among some other options, I made sure to specify-DBUILD_SHARED_LIBS=ON, in order to get a shared library (libfmt will build astatic one by default). And then I ran make -j package, and it worked like acharm: I got a libfmt-dev-7.1.3-Linux.deb file in my build directory, whichlooked quite good when I inspected it with dpkg -clibfmt-dev-7.1.3-Linux.deb, and also installed perfectly!
All the steps have been completed with success. When I open the directory myprog-1.1.0/debian, I find something, which looks like to a Debian package. But my libraries are not in there, they are under myprog-1.1.0/debian/tmp/usr/lib/....
The Holoscan SDK Debian package is part of NVIDIA Holoscan, the AI sensor processing platform that combines hardware systems for low-latency sensor and network connectivity, optimized libraries for data processing and AI, and core microservices to run streaming, imaging, and other applications, from embedded to edge to cloud. It can be used to build streaming AI pipelines for a variety of domains, including Medical Devices, High Performance Computing at the Edge, Industrial Inspection and more.
f5d0e4f075