deb file is an archive in the format ar, containing setup files programs, information about the program, as well as scripts (command files) that are executed before and after installation and removal of the program (the presence of scripts is optional - they may not be included in the package).
The format of the deb file is described in the man pages (man pages) deb(5) - this help is displayed if you type the command man deb in the terminal. There are also many pages on the Internet containing this information - just type deb(5) into the search bar to find them. This manual is not included here because the official Debian Developers Manual, the Package Format Reference (which, at the time of this writing, is located at http://www.debian.org/doc/manuals/debian-faq/ch- pkg_basics.en.html) it is written that the format of packages can change, and therefore it is recommended to use the dpkg-deb utility to work with them. You can get help with the dpkg-deb utility by typing man dpkg-deb in a terminal.
The work of the GUI-deb program is precisely to create a directory containing the necessary data, and run the dpkg-deb program, specifying this directory and other necessary parameters.
The correct directory needed for dpkg-deb to create an installation package must first of all contain a "DEBIAN" subdirectory. This directory should contain all data that is not copied to the system, but used directly by programs for working with packages - information about the package, scripts executed before and after installation, etc. Any files contained in the DEBIAN directory will not end up on the file system of the computer on which the package is installed when the package is installed.
Outside the "DEBIAN" directory are those files that will be copied to the file system of the computer on which the package will be installed. The files must be located in the directories in which they will be placed when installing the package. That is, inside the directory created for dpkg-deb, a copy of the parts of the file system we need should be created - as if this directory were its root ("/"). That is, for example, if the name of the directory on the basis of which the package will be created is "~/TMP_DEBS/MyProgram", and it is necessary that when installing in file system the file "MyProgram.png" was written to the "/usr/share/pixmaps" directory - you need to create the "usr" directory in the "~/TMP_DEBS/MyProgram" directory, in it - the "share" directory, inside "share" - the "pixmaps" directory ", and already in the "pixmaps" directory place the file "MyProgram.png". As a result, the full path to the file will be "~/TMP_DEBS/MyProgram/usr/share/pixmaps/MyProgram.png". When creating a package, a part of the "~/TMP_DEBS/MyProgram" directory will be truncated, and during installation, the "MyProgram.png" file will just get to the desired address "/usr/share/pixmaps". Thus, the necessary directories must be created for each file.
After creating the directory, all that remains is to run dpkg-deb, passing the necessary parameters. The most important dpkg-deb options for building packages are described in the section "Command line options for the dpkg-deb utility" . If there are no errors in the control file, the installation package will be created.
I described building the program from source, as well as creating a simple deb package. This time I want to dwell on their creation in more detail. This guide does not claim to be a guide for developers or maintainers, so at the end I will provide links to detailed guides from developers Debian.
There are quite a few ways to create a deb package. I won't describe the large build systems that are used on build servers here, because most people don't need to. I will describe two of the most simple ways creating your package. First of all, we need to install some tools for work:
sudo apt-get install build-essential git automake devscripts make libtool fakeroot automake autotools-dev
Next, you need to create a digital key. This step is optional, but if you plan to redistribute your packages, it would be extremely wise to sign them with your key. This will allow the user who downloaded your package to verify that it was you who created it. To create a key, you can use graphic utilities ( sea horse, kgpg) or in the terminal:
DEBEMAIL="your E-Mail that you specified when creating the key"
DEBFULLNAME="Your name (or alias)"
export DEBEMAIL DEBFULLNAME
This will automatically add your digital signature when signing packages. Next, we need an archive with source code. I will conduct a simple example, because, depending on the complexity of the program, additional configuration is required (creation of post-installation scripts, assembly rules, etc.). Suppose we have an archive with the source code of the program "myprogramm" - myprogramm_1.0.tar.gz. Unpack it to your home directory (or any where you prefer). Please note: the directory after unpacking must have the name myprogramm-1.0. Name followed by a dash - version number. Now open a terminal and run:
cd ~/myprogramm-1.0
dh_make --createorig
We moved into the source directory and created an archive with it and a basic debianization. After the second command, a message will be displayed where you need to select the package type: s (single, single), m (multiple, several packages), l (library, library), k (kernel module, kernel module). In our case, this is s. Now we need to set things up a bit. Go to /myprogramm-1.0/debian directory and open the file control in any text editor. This is the main file for building the package. It contains all the basic information. It looks something like this:
Source: myprogram
Section: admin
Priority: optional
Maintainer: Aleksey Samoilov
Build-Depends: debhelper (>= 5)
Standards-Version: 3.9.6
Homepage: http://www.example.com
Package: myprogram
Architecture: all
Depends: $(shlib:Depends), $(misc:Depends)
Section: admin
Priority: optional
Description: My new program
My programm is a simple example to build your own deb-package
Let's go in order. The first section contains the name of the source package. Next, the software section (in this case admin). Then the priority (optional), the name of the maintainer and his E-Mail (i.e. yours), build dependencies (packages needed for building), version of the standard (on this moment 3.9.7), followed by the name of the package after the build, the architecture for which it is built (all means all supported architectures), software section, priority, short description And Full description. Since our example is simple, this is enough to get started. You can also open the file copyright and enter your name and e-mail there. In file changelog contains a list of changes for each version of this software. Since this is the first build, you need to indicate that this is First Release, and also close a certain bug (lack of this package in the repository). The bug number can be written from the bulldozer. If you are rebuilding a package, first change its version with the command dch-i Files in the debian directory with extensions .ex are examples. When building more complex packages, you will need these additional files. These are, for example, post-installation scripts ( postinst), a file that checks for new version tarball with source code ( watch) and so on. File rules is a makefile, the rules for assembling the package. For simple programs you can not change it, in other cases - you need to edit it, to specify the assembly parameters, or install icons. Many things.
Now that you have filled in the control file, you can start building. To do this, while in the directory with the source code, run the command debuild. The system will configure, compile the program, pack it into a package, check for common errors during debianization and ask you to enter the password for your key twice (if you did not create it, then nothing will happen). Now in the directory one level higher (in our case, in the home directory), you will see several files, among which the deb package you are looking for. Now it can be installed with the command sudo dpkg -i myprogramm-1.0-1.deb or in the Gdebi graphical manager.
This is how you can assemble a simple package. But what if you don't want to litter the system with a bunch of build dependencies? Moreover, when building some packages, some modified files may be used. For example, newer versions of libraries, if you updated the system from backports, or various changes in configs. On similar cases you can use virtual machine, container, or use a special tool called pbulder. pbuilder is a tool for creating a clean environment that contains only what is needed for the build. The system does not get clogged. junk files, and the assembly of the program takes place in the laboratory. Install:
sudo apt install pbuilder
I will give an example of my config, with which you can build packages not only for different Debian releases, but also for Ubuntu.
sudo nano /etc/pbuilderrc
Paste the following content:
STABLE_CODENAME="stable"
OLDSTABLE_CODENAME="oldstable"
DEBIAN_SUITES=($UNSTABLE_CODENAME, $TESTING_CODENAME, $STABLE_CODENAME $STABLE_BACKPORTS_SUITE $OLDSTABLE_CODENAME
"sid" "stretch" "jessie" "wheezy")
UBUNTU_SUITES=("precise" "trusty" "xenial")
UBUNTU_MIRROR="mirror.yandex.ru"
DEBIAN_MIRROR="mirror.yandex.ru"
: $(DIST:="$(lsb_release --short --codename)")
: $(ARCH:="$(dpkg --print-architecture)")
NAME="$DIST"
if [ -n "$(ARCH)" ]; then
NAME="$NAME-$ARCH"
# the next line is needed in order to build for different architectures
DEBOOTSTRAPOPTS=("--arch" "$ARCH" "$(DEBOOTSTRAPOPTS[@])")
fi
BASETGZ="/home/sunderland93/pbuilder/$NAME-base.tgz"
DISTRIBUTION="$DIST"
BUILDRESULT="/home/sunderland93/pbuilder/$DIST/result/"
APTCACHE="/home/sunderland93/pbuilder/$NAME/aptcache/"
BUILDPLACE="/home/sunderland93/pbuilder/build/"
if $(echo $(DEBIAN_SUITES[@]) | grep -q $DIST); then
MIRRORSITE="http://$DEBIAN_MIRROR/debian/"
COMPONENTS="main contrib non-free"
elif $(echo $(UBUNTU_SUITES[@]) | grep -q $DIST); then
MIRRORSITE="http://$UBUNTU_MIRROR/ubuntu/"
COMPONENTS="main restricted universe multiverse"
else
echo "Unknown distribution: @DIST"
exit 1
fi
export DPKG_GENSYMBOLS_CHECK_LEVEL=4
USE_PDEBUILD_INTERNAL=yes
Replace sunderland93 with your system name. Thus, we will be able to build packages for Debian 7, 8, testing and unstable, as well as for Ubuntu 12.04, 14.04 and 16.04. Dependencies downloaded for assembly will be in pbuilder/distribution name/aptcache. By the way, this is very useful - we will have a base archive that will not be clogged with left-handed dependencies and weigh several gigabytes. And the environment will be prepared individually for each program. It is possible to sew these dependencies into the base archive, but I do not recommend doing this. Now let's create a base archive containing a clean build environment. Let's take Debian 8 64-bit as an example:
sudo DIST=jessie ARCH=amd64 pbuilder --create
The archive creation process will begin. After it is ready, you can start building the program. To do this, open a terminal, go to the directory with the source code, and execute:
sudo DIST=jessieARCH=amd64 pdebuild
And we are waiting. The downloaded packages will be cached, and next time I will not download. After building, the finished deb package will appear in the directory pbuilder/jessie/result. That's all.
Today I will tell on an abstract example how Right create *.deb package for Ubuntu/Debian. We will make the package binary. Packages that compile binaries from sources are not considered here: having mastered the knowledge presented below, in the future, using ready-made examples, you can understand the essence and act by analogy :)
There will be no unnecessary fuss “manually” in the article: the package format has evolved into a fairly simple, and most importantly, logical structure, and everything is done literally on the knee, using a couple of specialized utilities.
As a bonus, at the end of the article there will be an example of quickly creating your own local repository: installing packages from the repository allows you to automatically track dependencies, and of course! - install all one console command on multiple machines :)
For those who do not want to go into the powerful software installation system in Linux, I recommend visiting the CheckInstall program site: it automatically creates a deb package from the “make install” command;) And we, along with the curious -
| Attribute | Description | Examples |
|---|---|---|
| - basic - | ||
| package: | Package name: - only Latin, numbers, and hyphens. Name used during installation: apt-get install |
Package: supersh |
| version: | The version of the package (and the program inside). Used to determine whether to update. The format adopted is:<версия_программы>-<версия_пакета> . I recommend Always indicate the version of the package: when changing the structure of the package, the number increases by one. Valid characters are quite free: you can use the date and letters. See examples today in your repository :) |
Version: 1.0-1 Version: 2009.12.12-1 |
| Provides | The application name (possibly virtual) that is registered with the system as a result of installing this package. Rarely used: mostly if you need to change the package name, or if more than one package offers the same functionality. For example, the Apache and nginx packages provide the httpd daemon capability: Provides: httpd You must have encountered an error when trying to install: "is a virtual package". This is what it is :) |
Provides: supersh |
| maintainer | The name and email of the package maintainer: the person who "debianized" the application. The format is arbitrary, but the name is accepted |
Maintainer: o_O Tync |
| architecture | The processor architecture for which the package is intended. Valid values: i386, amd64, all, source all is used for scripts: they are portable, right? :) source is used for compiled source packages |
Architecture: all |
| Section | Specifies the task for which the application is typically used (application group). Possible values: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free , oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11 |
Section: misc |
| Description | Description of the package. The description consists of two parts: a short description (70 characters) on the same line, and a long description on subsequent lines, starting with a space. In the extended description, all newlines are ignored. \n is inserted using a single dot. |
Description: short. ␣Long ␣goes here. ␣. ␣New line. |
| - connections and dependencies - | ||
| Depends | A comma-separated list of packages that are required to install this package. After the package name, you can specify a version limit in parentheses using the operators:<<, =, >>, <=, >=. If the operator is not specified, >= is used. |
Depends: dpkg, libz (>= 1.2.3), jpeg (= 6b), png (< 2.0) |
| Pre-Depends | List of packages that are required during the installation of this package. These dependencies may be required for package installation scripts: for example, the flash-installer package requires wget You can use version restrictions (see Depends). |
Pre-Depends: wget (>= 1.0) |
| Conflicts | List of packages that cannot be installed at the same time as this. The installation will fail if at least one of the listed packages is already installed. |
conflicts: crapscript |
| Replaces | List of packages whose files are modified by this package. Required if you create a "patch package" that changes something: otherwise, when replacing the files of someone else's package, an installation error will occur. For example, I have such a package that patches UT2004 and removes the sound of a homing rocket launcher :) |
Replaces: ut2004 |
| Recommendations | List of packages recommended for installation These packages are optional, but are usually used in conjunction with the current |
Recommended: superplatform |
| Suggestions | List of packages offered for installation. These packages are optional, but the program works even better with them :) In theory, the package manager should offer to install them. |
Suggests: supersh-modules |
| Build-Depends | (Only for Architecture: source) List of packages required to compile sources. Same as Depends, but logically separated. |
Build-Depends: cmake |
| - extra - | ||
| Installed-Size | Size of package files in kilobytes. Just a number rounded to the nearest integer. Used by the package manager to determine the total disk space required. |
Installed-Size: 3 |
| priority | Packet priority: how important it is in the system Possible values: extra, optional, standard, important, required (such packages are not removed at all!). |
Priority: optional |
| Essential | If you set this attribute to "yes", the package cannot be removed. | Essential: yes |
| origin | String: where the programs in the package come from. Usually the URL of the author's site, mail or name is used. | Origin: brain |
| X source | Full link to *.tar.gz source archive | X-Source: ...*.tgz |
O_O Tync
Working with package installation scripts will be discussed later.
Thanks Condorious for the tip :)
# ======[ Trap Errors ]======#
set -E # let shell functions inherit ERR trap
# Trap non-normal exit signals:
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler(
local exit_status=$(1:-$?)
logger -s -p "syslog.err" -t "ootync.deb" "supersh.deb script "$0" error code $exit_status (line $BASH_LINENO: "$BASH_COMMAND")"
exit $exit_status
}
Your setup script code...
WARNING: the disc has not yet been widely tested, check again! I came across the impossibility of debugging quite recently :)
Template - unique (within the same package) template identifier. If a script needs to call a specific dialog, this name is used.
Type - template type. The following types are defined: string, password, boolean, select, multiselect, text, note, error.
Default-value - the default value: the user can simply agree with it.
Description - as in the control file, it consists of two fields: a short description, and long text. The first is the title of the "window", the second is a more detailed description of what is required from the user. It is recommended not to use words like “enter”, but immediately the essence: “Script greeting”, “Mount point”, ...
| Type | Template description |
|---|---|
| string | Text string prompt |
| password | Password prompt. There is no Default value for this template type for obvious reasons :) |
| boolean | Checkmark :) Has the string value "true" or "false" |
| select | Possibility to choose one of several options. Choices: yes, no, maybe |
| multiselect | Ability to select multiple options with checkboxes. Options are offered in an additional template attribute: Choices: sex, drugs, rock-n-roll |
| text | Displays text: some not very important information |
| note | Displays text: important information |
| error | Displays text on the screen: very important information, critical. |
# Connecting debconf commands
Case "$1" in
configure|reconfigure)
# Request
# Handling the response
greeting="$RET"
echo "$greeting" > /etc/supersh/greeting.txt
;;
*)
echo "config called with unknown argument \`$1"" >&2
exit 1
;;
esac
# Request
db_input medium "supersh/greeting" || true # initialization
db_go || true # display the request on the screen
# Handling the response
db_get "supersh/greeting" # Get value into $RET variable
greeting="$RET"
echo "$greeting" > /etc/supersh/greeting.txt
Here already lies an unpleasant ambush: note that the priority of the medium dialog is passed to the db_input function. For debconf, you can set a minimum priority: dialogs with a priority below which are not displayed, but the default value (Default of the template) is taken! To prevent this EXACTLY from happening, we use the critical priority :) In addition, when installing from the GUI, the threshold for displaying questions is higher, and many of them are not displayed at all.
Possible priorities are: low - default is always used, medium - default is usually quite appropriate, high - default is undesirable, critical - user attention is vital.
|| true is used to prevent the script from dying because of the "-e" option passed to bash.
In this script, it is also recommended to use that pig to catch errors, otherwise the redistributable package may have problems when debugging :)
All the subtleties of using debconf (functions, methods, options, error codes) are described in a rather verbose mana: man debconf-devel .
One last thing: when a package is removed with the purge command, debconf must also purge the package information from its database. For example, it saves the user's choice on db_input queries.
To clean up this data, you need to add the following to the postinst script:
if [ "$1" == "purge" ] && [ -e /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
db_purge
fi
In our business of creating a simple repository, all fields do not play a fundamental role, and are used only to visually determine “what is what” :)
I will try to explain the process of creating deb packages as clearly as possible using ruby-zookeper as an example. I warn you right away that the ruby gems packaging method I described is wrong, it's better to use gem2deb for this, but since build ruby-zookeper from source using gem2deb latest version I did not succeed, then here is the easiest assembly method.
If you will be building ruby packages via gem2deb as recommended, it's better to add the line
Export DH_RUBY_IGNORE_TESTS=all/export DH_RUBY_IGNORE_TESTS=all
in debian/rules.
Because Since we will be building ruby code, we will need ruby and a set of tools for building deb packages.
sudo apt-get install ruby dpkg-dev
If you have an old version of ruby, then it does not have a gem command, you will also have to install the rubygems package or update ruby.
Now let's install the gem fpm, which will collect the deb package for us.
sudo gem install fpm fpm -s gem -t deb zookeeper
In the current directory, we have the rubygem-zookeeper_1.4.11_amd64.deb package, it would seem that the matter is already in the bag, but because we need a source package so that we can build a deb from it, for example in OBS, then we will continue.
Create a build directory
cp rubygem-zookeeper_1.4.11_amd64.deb ~/ cd mkdir -p ruby-zookeeper/fakeroot cd ruby-zookeeper/fakeroot
Let's extract the contents of the newly built package into it.
dpkg-deb -R ~/rubygem-zookeeper_1.4.11_amd64.deb ruby-zookeeper_1.4.11-1
Now we will create the files needed to build the package. They must be in the debian directory. We can copy some of the files from the unpacked package.
mkdir debian cp rubygem-zookeeper_1.4.11-1/DEBIAN/control debian/control
Let's edit it to the next state. Don't forget to change Maintainer
Source: ruby-zookeeper Maintainer:
We still need debian/rules. Let's create it. override_dh_shlibdeps is needed in order not to check the linking of zookeeper libraries, because she doesn't get through.
#!/usr/bin/make -f # -*- makefile -*- %: dh $@ override_dh_shlibdeps: true
Tabs in debian/rules are required, you cannot replace them with spaces. Let's make it executable.
Chmod +x debian/rules
Usr/* var/*
Now let's create debian/changelog and write there:
Ruby-zookeeper (1.4.11-1) UNRELEASED; urgent=medium * Initial release -- root
We also need debian/compat
Echo 7 > debian/compat
Let's copy the files that will be installed to a local directory and delete the folder with the unpacked package, we won't need it anymore.
Mv ruby-zookeeper_1.4.11-1/(usr,var) . rm -r ruby-zookeeper_1.4.11-1
Let's build a new package, as well as a source package.
dpkg-buildpackage -rfakeroot -uc -F
In the directory above, we will have all the necessary files.
Ll .. total 5528 drwxr-xr-x 3 root root 4096 Dec 20 13:32 ./ drwx------ 12 root root 4096 Dec 20 13:31 ../ drwxr-xr-x 5 root root 4096 Dec 20 13:28 fakeroot/ -rw-r--r-- 1 root root 1261 Dec 20 13:32 ruby-zookeeper_1.4.11-1_amd64.changes -rw-r--r-- 1 root root 2375044 Dec 20 13: 32 ruby-zookeeper_1.4.11-1_amd64.deb -rw-r--r-- 1 root root 565 Dec 20 13:32 ruby-zookeeper_1.4.11-1.dsc -rw-r--r-- 1 root root 3263381 Dec 20 13:32 ruby-zookeeper_1.4.11-1.tar.gz
You can check the contents of the resulting deb package
Create a list of packages:
$ dpkg-scanpackages . /dev/null | gzip -9c > ./Packages.gzMaybe we will get a message like:
dpkg-scanpackages: warning: Packages in archive but missing from override file: dpkg-scanpackages: warning: fossil linux-headers-3.8.0-avl9-pae linux-image-3.8.0-avl9-pae pdfsam sublimetext virtualbox-4.2 xserver -xorg-input-wacom zotero dpkg-scanpackages: info: Wrote 8 entries to output Packages file.
We now have 8 packages in our repository. Ok, let's add our repository to the file:
Deb file:///home/username/zips/virensdebianrepository ./
Now you need to update the list of packages so that they become available for installation:
# apt-get install sublimetext
Special thanks to Com. brainstream, which pointed out a bug in a post with rendering of the PRE environment. This happens when you trust Haskell crafts like pandoc :-)
Yes, if you have something to add - write in the comments, but keep in mind that the post is in haste, without the need to re-read the Debian Packaging Guidelines tomes and other quantum physics.
Anonymous comments...
There is an error in your text:
"Now, in order to install Skype, just do:
# apt-get install sublimetext"
Anonymous comments...
You can unpack packages using dpkg-deb:
$ dpkg-deb -x what.deb where/
Anonymous comments...
I have always used dpkg -e and dpkg -x to fully extract a package and quickly fix files or dependencies in control files. I also used checkinstall instead of make install to create a package when compiling something. I think these utilities are worth mentioning.
virens comments...Building packages from source in Debian is evil! I now recall my experience:
1. The deb-package must contain a maintainer and other nonsense, without which (surprise-surprise!) the package will not be built.
2. Have you assembled, installed and think that's it? No luck, good aptitude can blow a package to hell when installing something else. You know that feeling: how? Where? What? I already installed this package! Well, this is his aptitude - all of himself is Orthodox, which means that he is patriarchal and does not allow freethinking.
3. Therefore, a maneuver is urgently needed: aptitude hold package. "What, is it holding up well? And now be kind - unstick it!" (c) Because from now on aptitude will complain that it can't resolve dependencies without tearing down your package.
4. At this point, my nerves gave out... And I discovered Gentoo, and my hair became soft and silky again!
virens comments...@iv_vl comments...
And I discovered Gentoo, and my hair...
Brazen PR Genta?! IN my blogger??? There is no way! ;-)
1. The deb package must have a maintainer and other nonsense
Standard policy - you need to know who to punch in the face for a broken package :-) And then, it’s different better than that the bedlam that is going on in RPM fedoras and zyuzes.
2. Have you assembled, installed and think that's it? No luck, good aptitude can blow a package to hell when installing something else.
Only if you put a package old version- for example, I have a hold on IceWM, which I installed from Lenny (the idiot maintainer stuffed ice with a broken tray into Squeeze). Aptitude will warn you before such maneuvers, if anything.
3. Therefore, a maneuver is urgently needed: aptitude hold package.... aptitude will swear that it is not able to resolve dependencies
This is a lie and a provocation: unless you put hold on something like gcc or glibc, it will normally resolve dependencies. Unlike RPMs, who like to give up immediately in the style of "Well, I couldn't, I couldn't" :-)
There can be problems with debugging, that's a fact, but it's better than frying bacon and eggs on the CPU while waiting for fresh KDE gentoy to finish...
4. On this, my nerves passed ...
Somehow you quickly blew up. By the way, what about dependencies in Gent? How do you live there with swearing at every sneeze?
I am ... not trolling for the sake of .... people are interested.
