Once again about deb packages
Deb packages are a very handy tool, especially if you know how to use it. I will try to share my own experience in this matter.
To start creating deb packages, you need to install several packages:
In order for dh_make and other utilities to work with the source folder, you need to bring it into a specific form.
The folder should be called the package name-version . Those. if I have a Plugins folder with program version 0.1, then I create a folder named plugins-0.1 .
')
Now you need to create an archive with this folder. The archive must contain in the name * .orig.tar.gz , ie:
The last preparatory step is to create a debian folder in the source folder with a lot of service files. To do this, you need to run the command:
During the execution of this command, a question will be asked about what type of archive we are creating, the simplest is single.
All package configuration is done by editing the files in the debian directory. Consider the files that we will use:
In addition to these files, many * .ex files will be created in the debian folder, which are examples for configuring various things, but we will not use them and therefore they need to be deleted.
This file contains the change history of the package and the current version of the package. Let's look at its contents:
At the beginning is the name of the package - libvksplugins , then its version. The version is divided into two parts by the symbol "-". The first part shows the version of the program in the package, the second “revision” of the package. Revision is a version of a package, i.e. if before such a package was not, then the revision is equal to 1. If the package with this version of the program was already there, but there were changes in it, then the revision increases.
The word unstable indicates that the package is not stable, i.e. It has not been properly tested on users' machines.
The inscription urgency = low indicates the urgency of the change. Since There is no urgency, the value is low . If we were making a package to fix a serious vulnerability or error, the value could be set to high .
After the first line there is an empty line, followed by the first record:
In Debian, the changelog is used to automatically close errors in bug tracking systems in software products. Since In this case, I do not use such a system, then this line takes the form:
The last line is the signature of the person who made the entry. It contains the name and address, as well as the date of the change.
After installing the deb package, the changelog file is set to
The debian / control file is the main config when creating a deb package. Here is an example of such a file:
You can see that the file is divided into sections using empty lines. Each section describes one package created from the source folder. Consider them in order:
Source This section says that you need to create a source package. The parameter is libvksplugins , which means the source package will be called libvksplugins .
Priority This section sets the priority of the package. Since Since the system can do without a new package, the value of the section is set to optional . Those. This package is optional for installation. Read more about the priorities here .
Maintainer This section describes the contacts of the person creating the package. Its format is quite simple and does not require additional description.
Build-Depends One of the most important sections for installing package dependencies. Dependencies specified in this section must be met in order to be able to assemble a package. Those. The list of dependencies for assembly and installation may vary.
You can see that the dependencies are debhelper (> = 9), cmake . The debhelper dependency (> = 9) is set for all packages by default. It is needed for the correct operation of programs like dh_ * .
The second cmake element was added because the source folder contained the CMakeLists.txt file, i.e. for assembly the CMake assembly system is used. In order to find out what dependencies the program has, you can read its documentation. In addition, you can use the dpkg-depcheck command . This command should run like this:
But, since when using CMake there is no configuration script, then I use it like this:
Notable here can be noted:
The rest are data dependencies. Moreover, cmake is already in the list of assembly dependencies. In principle, you can leave it as is or specify the version used:
At the same time, CMakeLists.txt contains the version of cmake that should be used:
I think that the developer knows better, and therefore I indicate the version from CMakeLists.txt. For Qt 4, everything is clear with the version numbers, but to clear our conscience, we will also check their versions:
Those. for Qt 4 we indicate version 4.8.6:
Standards-Version The version of the standard according to which the file was created. This value does not need to be changed.
Section . Package section, i.e. a group of packages that performs one task. Debian Policy Section 2.4 describes this issue in more detail.
Homepage Project homepage . Since I wrote this code and it does not have a page, I just delete this line.
Vcs- * Links to project repositories. I don’t have them either, so I delete these lines.
Other packages After the section of the file where the source package is described, there are sections that describe other packages created from the source package. Package creation scheme:
From the diagram it is clear that from the source of the program, I want to get 4 packages:
The question arises, why so many packages? There may be several answers to it, if you read the relevant discussions on stackoverflow.com, then the basic idea of ​​splitting is that most users do not need header files and documentation, so the separation of these files helps reduce the network load and the speed of program installation.
My personal answer to this question is that such a partition helps to structure the program according to how I want to work with it. For development, I put the dev package, but not for use.
In addition to the packages described above, you can create a dbg package with a debug build of the program. This can be useful if the program crashes and you have a debugger on hand. However, I could not understand how to do it. Documentation does not answer this question. If you do as described in it, then I either get an empty package or get a bunch of errors during the build.
The diagram in the figure above shows that the source package is called libvksplugins_source , however, in the control file it is indicated that the source package will be called libvksplugins . In fact, it will actually be called libvksplugins , and the binary package will be called libvksplugins ... deb . The essence of this confusion is that the source package is a tar archive and service files, while a binary package is an archive with a deb extension.
Setting up the library package
The Architecture parameter sets the architecture of the package being built. The value any means that after the binaries are built, the desired architecture will be substituted by the build system. Those. on a 64-bit machine, you get a package ..._ amd64 ... and on a 32-bit package ..._ i386 ....
For packages containing scripts or texts, you need to specify the value as all .
The third line describes the dependencies of the package being created. Here is how it is described in the 4th chapter of the Debian Novice Developer's Guide:
Those. This line says that the package builder will determine the dependencies itself.
The last section of this section is the package description. The first line contains a short description, the subsequent lines contain a more detailed description. Detailed description, must have a specific format:
Setting up a package of header files A package with header files will be called libvksplugins-dev, here is its description:
In this example, the interesting line is Depends . It states that this package will depend on the libvksplugins library package , and ( = $ {binary: Version} ) says that strict binary version and developer package versions are needed. This is an important point because the header files must strictly match the binaries.
Setting up a documentation package A documentation is delivered with the library so that it is in a separate package, we add its description:
It should be all clear.
This file is the equivalent of a Makefile for building packages. By default, it is created as follows:
You can see that this is a bash script with the syntax Makefile. The only interesting construct here is
This is a template that for all purposes invokes the dh command with passing arguments to it. To build a package, it is important that the text dh $ @ read a tab character. Those. the indent is not a space, but a tabulation.
Since Since the sources use the CMake build system, you need to change this entry as follows:
After we have specified which packages we want to receive in debian / control , we need to specify which files to put into which package. For this, for each package name from the control file, you need to create two files in the debian folder. The first should be called the package .dirs , and the second package .install . The essence of the files is that the first indicates which folders to create for the package, and the second which files to include in the package.
Let's look at their contents:
The important point is the absence of the initial fraction in the paths and the absence of the fraction at the end of the path to the folder. By checking where CMake installs the library files, you can generate the following files:
Since my sources, I have no additional descriptions and limitations of copyright, so I delete all unnecessary files from the debian directory.
After setup, building packages is quite simple, you need to execute the command in the project folder (which includes the debian subfolder):
The -us -uc options say that you do not need to sign the gpg key with the created packages. They can not be used if the default gpg signing key is configured. I did not understand how to specify the default signature key. If everything went well, then we have a set of packages in the folder above:
If you have read to here - then you love to read.
This text is the result of my experience in deploying deb packages at work. Experience has shown that having a network repository (reprepro) and attentive version tracking allows you to easily upgrade and test different software versions on a fleet of 30 machines with Astra Linux 1.3, 1.4 and Elbrus OS systems.
Training
To start creating deb packages, you need to install several packages:
$ sudo apt-get install dh_make Preparing the source folder
In order for dh_make and other utilities to work with the source folder, you need to bring it into a specific form.
The folder should be called the package name-version . Those. if I have a Plugins folder with program version 0.1, then I create a folder named plugins-0.1 .
')
$ ls VKSPlugins $ mv VKSPlugins/ libvksplugins-0.1 $ ls libvksplugins-0.1 Now you need to create an archive with this folder. The archive must contain in the name * .orig.tar.gz , ie:
$ tar -zcf libvksplugins_0.1.orig.tar.gz libvksplugins-0.1 $ ls libvksplugins-0.1 libvksplugins_0.1.orig.tar.gz The last preparatory step is to create a debian folder in the source folder with a lot of service files. To do this, you need to run the command:
$ cd libvksplugins-0.1/ $ dh_make Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch? [s/i/m/l/k/n] l Maintainer name : User Name Email-Address : user@name.ru Date : Wed, 19 Aug 2015 14:55:53 +0300 Package Name : libvksplugins Version : 0.1 License : blank Type of Package : Single Hit <enter> to confirm: Skipping creating ../libvksplugins_0.1.orig.tar.gz because it already exists Done. Please edit the files in the debian/ subdirectory now. plugins uses a configure script, so you probably don't have to edit the Makefiles. During the execution of this command, a question will be asked about what type of archive we are creating, the simplest is single.
About package type
In fact, the documentation says, select the option only single . Since I could not understand all the requirements for a library type package, but I am quite satisfied with the result, then the description will go further about a library type package.
Package Customization
All package configuration is done by editing the files in the debian directory. Consider the files that we will use:
- changelog - package history.
- control - the main package configuration;
- rules is the equivalent of a package Makefile
In addition to these files, many * .ex files will be created in the debian folder, which are examples for configuring various things, but we will not use them and therefore they need to be deleted.
changelog
This file contains the change history of the package and the current version of the package. Let's look at its contents:
$ cat changelog libvksplugins (0.1-1) unstable; urgency=low * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> -- User Name <user@name.ru> Wed, 19 Aug 2015 15:03:51 +0300 At the beginning is the name of the package - libvksplugins , then its version. The version is divided into two parts by the symbol "-". The first part shows the version of the program in the package, the second “revision” of the package. Revision is a version of a package, i.e. if before such a package was not, then the revision is equal to 1. If the package with this version of the program was already there, but there were changes in it, then the revision increases.
The word unstable indicates that the package is not stable, i.e. It has not been properly tested on users' machines.
The inscription urgency = low indicates the urgency of the change. Since There is no urgency, the value is low . If we were making a package to fix a serious vulnerability or error, the value could be set to high .
After the first line there is an empty line, followed by the first record:
* Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> In Debian, the changelog is used to automatically close errors in bug tracking systems in software products. Since In this case, I do not use such a system, then this line takes the form:
* Initial release
Comment
When checking the package with the lintian program, the absence of Closes: #XXXX is considered an error.
The last line is the signature of the person who made the entry. It contains the name and address, as well as the date of the change.
After installing the deb package, the changelog file is set to
/usr/share/doc/<>/changelog.Debian.gz
control
The debian / control file is the main config when creating a deb package. Here is an example of such a file:
$ cat control Source: libvksplugins Priority: optional Maintainer: User Name <user@name.ru> Build-Depends: debhelper (>= 9), cmake Standards-Version: 3.9.5 Section: libs Homepage: <insert the upstream URL, if relevant> #Vcs-Git: git://anonscm.debian.org/collab-maint/plugins.git #Vcs-Browser: http://anonscm.debian.org/?p=collab-maint/plugins.git;a=summary Package: libvksplugins-dev Section: libdevel Architecture: any Depends: libvkspluginsBROKEN (= ${binary:Version}), ${misc:Depends} Description: <insert up to 60 chars description> <insert long description, indented with spaces> Package: libvkspluginsBROKEN Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: <insert up to 60 chars description> <insert long description, indented with spaces> You can see that the file is divided into sections using empty lines. Each section describes one package created from the source folder. Consider them in order:
Source This section says that you need to create a source package. The parameter is libvksplugins , which means the source package will be called libvksplugins .
Priority This section sets the priority of the package. Since Since the system can do without a new package, the value of the section is set to optional . Those. This package is optional for installation. Read more about the priorities here .
Maintainer This section describes the contacts of the person creating the package. Its format is quite simple and does not require additional description.
Build-Depends One of the most important sections for installing package dependencies. Dependencies specified in this section must be met in order to be able to assemble a package. Those. The list of dependencies for assembly and installation may vary.
You can see that the dependencies are debhelper (> = 9), cmake . The debhelper dependency (> = 9) is set for all packages by default. It is needed for the correct operation of programs like dh_ * .
The second cmake element was added because the source folder contained the CMakeLists.txt file, i.e. for assembly the CMake assembly system is used. In order to find out what dependencies the program has, you can read its documentation. In addition, you can use the dpkg-depcheck command . This command should run like this:
$ dpkg-depcheck -d ./configure But, since when using CMake there is no configuration script, then I use it like this:
$ mkdir build && cd build $ dpkg-depcheck -d cmake ../ ..... Packages needed: libxml2:amd64 cmake libkrb5support0:amd64 language-pack-ru-base libnettle4:amd64 ..... libedit2:amd64 libtasn1-6:amd64 qt4-qmake libgssapi-krb5-2:amd64 libhcrypto4-heimdal:amd64 ..... libroken18-heimdal:amd64 libsqlite3-0:amd64 libqt4-dev libssl1.0.0:amd64 ..... Notable here can be noted:
cmake
qt4-qmake
libqt4-dev
The rest are data dependencies. Moreover, cmake is already in the list of assembly dependencies. In principle, you can leave it as is or specify the version used:
$ apt-cache show cmake | grep Version: Version: 2.8.12.2-0ubuntu6 At the same time, CMakeLists.txt contains the version of cmake that should be used:
$ cat CMakeLists.txt | grep cmake_minimum cmake_minimum_required(VERSION 2.8.4) I think that the developer knows better, and therefore I indicate the version from CMakeLists.txt. For Qt 4, everything is clear with the version numbers, but to clear our conscience, we will also check their versions:
$ apt-cache show qt4-qmake | grep Version: Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1.1 Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1 $ apt-cache show libqt4-dev | grep Version: Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1.1 Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1 Those. for Qt 4 we indicate version 4.8.6:
Build-Depends: debhelper (>= 9), cmake (>= 2.8.4), qt4-qmake (>= 4.8.6), libqt4-dev (>= 4.8.6) Standards-Version The version of the standard according to which the file was created. This value does not need to be changed.
Section . Package section, i.e. a group of packages that performs one task. Debian Policy Section 2.4 describes this issue in more detail.
Homepage Project homepage . Since I wrote this code and it does not have a page, I just delete this line.
Vcs- * Links to project repositories. I don’t have them either, so I delete these lines.
Other packages After the section of the file where the source package is described, there are sections that describe other packages created from the source package. Package creation scheme:
From the diagram it is clear that from the source of the program, I want to get 4 packages:
- source package;
- a package with a binary (the library itself);
- development package (header files);
- package of documentation.
The question arises, why so many packages? There may be several answers to it, if you read the relevant discussions on stackoverflow.com, then the basic idea of ​​splitting is that most users do not need header files and documentation, so the separation of these files helps reduce the network load and the speed of program installation.
My personal answer to this question is that such a partition helps to structure the program according to how I want to work with it. For development, I put the dev package, but not for use.
In addition to the packages described above, you can create a dbg package with a debug build of the program. This can be useful if the program crashes and you have a debugger on hand. However, I could not understand how to do it. Documentation does not answer this question. If you do as described in it, then I either get an empty package or get a bunch of errors during the build.
The diagram in the figure above shows that the source package is called libvksplugins_source , however, in the control file it is indicated that the source package will be called libvksplugins . In fact, it will actually be called libvksplugins , and the binary package will be called libvksplugins ... deb . The essence of this confusion is that the source package is a tar archive and service files, while a binary package is an archive with a deb extension.
Setting up the library package
Package: libvksplugins
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Library for creating plugins with VKS 2
This library provides a mechanism for creating plugins
to use in project VKS 2.
The Architecture parameter sets the architecture of the package being built. The value any means that after the binaries are built, the desired architecture will be substituted by the build system. Those. on a 64-bit machine, you get a package ..._ amd64 ... and on a 32-bit package ..._ i386 ....
For packages containing scripts or texts, you need to specify the value as all .
The third line describes the dependencies of the package being created. Here is how it is described in the 4th chapter of the Debian Novice Developer's Guide:
The dh_shlibdeps utility computes the dependencies of a binary package on shared libraries. It generates a list of ELF executables and shared libraries that it finds for each binary package. This list is substituted for $ {shlibs: Depends} .
The dh_perl utility calculates Perl dependencies. It generates a list of dependencies on perl or perlapi for each binary package. This list is substituted for $ {perl: Depends} .
Some debhelper package commands may add dependencies to your generated package. Each command generates a list of required packages for each binary package. This list is substituted for
$ {misc: Depends} .
The dh_gencontrol utility generates a DEBIAN / control file for each binary package, replacing $ {shlibs: Depends} , $ {perl: Depends} , $ {misc: Depends}, and so on with the values ​​obtained.
Those. This line says that the package builder will determine the dependencies itself.
The last section of this section is the package description. The first line contains a short description, the subsequent lines contain a more detailed description. Detailed description, must have a specific format:
- the line must begin with a space;
- the string must not be longer than 80 characters;
- A blank line must begin with a space and consist of a dot character.
Setting up a package of header files A package with header files will be called libvksplugins-dev, here is its description:
Package: libvksplugins-dev
Section: libdevel
Architecture: any
Depends: libvksplugins (= ${binary:Version}), ${misc:Depends}
Description: Development package for libvksplugins
This package provides development files for
library libvksplugins.
.
Also, it contains pkg-config file, to use.
In this example, the interesting line is Depends . It states that this package will depend on the libvksplugins library package , and ( = $ {binary: Version} ) says that strict binary version and developer package versions are needed. This is an important point because the header files must strictly match the binaries.
Setting up a documentation package A documentation is delivered with the library so that it is in a separate package, we add its description:
Package: libvksplugins-doc
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Documentation for libvksplugins
Package contains html documentation files for libvksplugins
It should be all clear.
rules
This file is the equivalent of a Makefile for building packages. By default, it is created as follows:
$ cat rules #!/usr/bin/make -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. #DH_VERBOSE = 1 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk # see FEATURE AREAS in dpkg-buildflags(1) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all # see ENVIRONMENT in dpkg-buildflags(1) # package maintainers to append CFLAGS #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic # package maintainers to append LDFLAGS #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed # main packaging script based on dh7 syntax %: dh $@ # debmake generated override targets # This is example for Cmake (See http://bugs.debian.org/641051 ) #override_dh_auto_configure: # dh_auto_configure -- \ # -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) You can see that this is a bash script with the syntax Makefile. The only interesting construct here is
%: dh $@ This is a template that for all purposes invokes the dh command with passing arguments to it. To build a package, it is important that the text dh $ @ read a tab character. Those. the indent is not a space, but a tabulation.
Since Since the sources use the CMake build system, you need to change this entry as follows:
%: dh $@ --buildsystem=cmake Package Contents
After we have specified which packages we want to receive in debian / control , we need to specify which files to put into which package. For this, for each package name from the control file, you need to create two files in the debian folder. The first should be called the package .dirs , and the second package .install . The essence of the files is that the first indicates which folders to create for the package, and the second which files to include in the package.
Let's look at their contents:
$ cat libvksplugins-dev.dirs usr/lib usr/include $ cat libvksplugins-dev.install usr/include/* usr/lib/lib*.a usr/lib/lib*.so usr/lib/pkgconfig/* usr/share/pkgconfig/* The important point is the absence of the initial fraction in the paths and the absence of the fraction at the end of the path to the folder. By checking where CMake installs the library files, you can generate the following files:
$ for item in $(ls libvksplugins*); do echo "$item:"; cat $item; done libvksplugins-dev.dirs: usr/include/dep572 usr/lib/pkgconfig libvksplugins-dev.install: usr/include/dep572/plugins/* usr/lib/dep572/lib*.so usr/lib/pkgconfig/* libvksplugins.dirs: usr/lib/dep572 libvksplugins-doc.dirs: usr/share/doc/libplugins-0.1 libvksplugins-doc.install: usr/share/doc/libplugins-0.1/*.tgz libvksplugins.install: usr/lib/dep572/lib*.so.* Complete setup
Since my sources, I have no additional descriptions and limitations of copyright, so I delete all unnecessary files from the debian directory.
Build Packages
After setup, building packages is quite simple, you need to execute the command in the project folder (which includes the debian subfolder):
$ dpkg-buildpackage -rfakeroot -us -uc The -us -uc options say that you do not need to sign the gpg key with the created packages. They can not be used if the default gpg signing key is configured. I did not understand how to specify the default signature key. If everything went well, then we have a set of packages in the folder above:
$ ls -l ../ 748 drwxrwxr-x 10 user user 4096 . 20 10:46 libvksplugins-0.1 -rw-rw-r-- 1 user user 2210 . 20 10:47 libvksplugins_0.1-1_amd64.changes -rw-r--r-- 1 user user 6418 . 20 10:47 libvksplugins_0.1-1_amd64.deb -rw-rw-r-- 1 user user 1504 . 20 10:46 libvksplugins_0.1-1.debian.tar.xz -rw-rw-r-- 1 user user 1008 . 20 10:46 libvksplugins_0.1-1.dsc -rw-rw-r-- 1 user user 36713 . 19 14:52 libvksplugins_0.1.orig.tar.gz -rw-r--r-- 1 user user 3262 . 20 10:47 libvksplugins-dev_0.1-1_amd64.deb -rw-r--r-- 1 user user 699564 . 20 10:47 libvksplugins-doc_0.1-1_all.deb Conclusion
If you have read to here - then you love to read.
This text is the result of my experience in deploying deb packages at work. Experience has shown that having a network repository (reprepro) and attentive version tracking allows you to easily upgrade and test different software versions on a fleet of 30 machines with Astra Linux 1.3, 1.4 and Elbrus OS systems.
Source: https://habr.com/ru/post/282217/
All Articles