deb file is an archive in the format ar containing installation files programs, information about the program, as well as scripts ( batch files), performed before and after installing and uninstalling the program (the presence of scripts is not mandatory - they may not be part of the package).

The deb file format is described in the deb(5) man pages - this help is displayed if you type man deb in a terminal. There are also quite a few pages on the Internet containing this information - just search for deb(5) to find them. This guide is not included here because the official Debian Developers Guide, Package Format Help (which at the time of writing this guide 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. Help on working with the dpkg-deb utility can be obtained by typing the command man dpkg-deb in the terminal.

The GUI-deb program works by creating a directory containing the necessary data and running the dpkg-deb program, specifying this directory and other necessary parameters.

The correct directory for dpkg-deb to create an installation package must first 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 performed before and after installation, etc. Any files contained in the DEBIAN directory will not be added to the file system of the computer on which the package is installed when the package is installed.

Outside the "DEBIAN" directory contains 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 directory "/usr/share/pixmaps" - you need to create a directory "usr" in the directory "~/TMP_DEBS/MyProgram", in it - a directory "share", inside "share" - a directory "pixmaps" ", and place the file "MyProgram.png" in the "pixmaps" directory. As a result, the full path to the file will be "~/TMP_DEBS/MyProgram/usr/share/pixmaps/MyProgram.png". When creating a package, part of the directory "~/TMP_DEBS/MyProgram" will be cut off, and during installation the file "MyProgram.png" will end up at 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 necessary dpkg-deb parameters for building packages are described in the section "Command line parameters for the dpkg-deb utility". If there are no errors in the control file, the installation package will be created.

Create a list of packages:

$dpkg-scanpackages. /dev/null | gzip -9c > ./Packages.gz

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.
There are now 8 packages in our repository. Great, 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 are available for installation:

# apt-get install sublimetext

Conclusion

Special thanks to comrade. brainstream, who pointed out a bug in the post with rendering the PRE environment. This happens when you trust Haskell crafts like pandoc :-)

Yes, if you have anything to add, write in the comments, but keep in mind that this is a quick post, without the need to re-read the Debian Packaging Guidelines 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...

Always used dpkg -e and dpkg -x to fully unpack a package and quickly edit 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.

Building packages from sources in Debian is from the evil one! I will now remember 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 all? No such luck, a good aptitude can destroy the package to hell when installing something else. Do you know that feeling: how? Where? What? I already installed this package!!! Well, that’s his aptitude - he’s all Orthodox, which means he’s patriarchal and doesn’t allow freethinking.

3. Therefore, an urgent maneuver is needed: aptitude hold package. “What, does it hold up well? Now be so kind as to peel it off!” (c) Because from now on aptitude will complain that it is not able to resolve dependencies without destroying your package.

4. At this point my nerves gave way... And I discovered Gentoo, and my hair became soft and silky again!

@iv_vl comments...
And I discovered Gentoo, and my hair...
Brazen PR of Genta?! IN mine blog??? There is no way! ;-)

1. The deb package must contain the maintainer and other nonsense
Standard policy - you need to know who to punch in the face for a broken package :-) And then, this is in any way better than the bedlam that is going on in RPM fedoras and zyuzas.

2. Have you assembled, installed and think that’s all? No such luck, a good aptitude can destroy the package to hell when installing something else.
Only if you put the package old version- for example, I have hold on IceWM, which I installed from Lenny (the idiot maintainer stuffed an 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: only if you haven’t put a hold on something like gcc or glibc, it will resolve dependencies normally. Unlike RPMs, who like to give up right away in the style of “Well, I couldn’t, I couldn’t” :-)

There may be problems with resolving dependencies, that's a fact, but it's better than frying eggs and bacon on the processor while waiting for the end of Genta's download of fresh KDE...

4. At this point my nerves gave way...
Somehow you were quickly blown away. By the way, what about dependencies in Ghent? How do you live there with a cough every time you sneeze?
I'm not doing this...for trolling's sake...people are interested.

Go beautiful language. One of its superpowers is the ability to compile everything into one binary. And this is very convenient, you can carry this file everywhere and use it on any machine. But I want to be able to install our program in a simple way.

Using deb packages, you can easily organize deployment to your servers. At the same time, you will have versioning and all that. I most often use ubuntu, so we will talk specifically about deb packages that can be installed/removed using the apt utilities.

What do you need to do to create your own repository with packages? You can use the same launchpad.net, for example. But, lately, it doesn't develop very well and looks unreliable. In addition, it is convenient to use it for your non-commercial developments, but using it for distributing enterprise software will be problematic.

Let's approach the problem from the other side. Firstly, we need to collect deb packages, and this is very easy to do ourselves using the dpkg-deb utility. Secondly, we need to place these packages somewhere, and for this we will use the super simple

Building packages

For all my projects I use . The project structure looks something like this:

Project/ |- bin/ | |- project |- src/ | |- github.com/ | |- 4gophers/ | |- project/ | |- main.go |- vendor/

When I run gb build, all the binaries are built in the bin folder. Thus, all we need is to simply add the specification of our future deb package directly to the project folder:

Mkdir project/DEBIAN touch project/DEBIAN/control

The result will be a structure like this:

Project/ |- DEBIAN/ | |- control |- bin/ | |- project |- src/ |- vendor/

In the control file we need to specify information about our package. Don't forget about the empty last line:

Package: project Priority: optional Section: devel Installed-Size: 100 Maintainer: Ivan Ivanov Architecture: i386 Version: 1.0 Depends: libc6 (>= 2.1) Description: Short description here Long description here

• Package - the name of your package
• Priority - package priority (optional, extra, standard, important, required) for ordinary programs it is better to set optional
• Section - the section it belongs to this package(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)
• Installed-Size - size of package files in kilobytes
• Maintainer - name and email of the package creator
• Architecture - processor architecture for which the package is intended (i386, amd64, all, source, all)
• Version - package version
• Depends - in this field you must specify the names of the packages on which your package depends (for example, libraries)
• Description - in the first line we write a short description of the package, in the rest in more detail

Everything that is in the project folder will go into the package. And the bin folder too. This folder contains our binary file that needs to be installed. In order for your files to end up in the desired directory on the user's computer, you need to create the appropriate directory structure inside your project folder.

It is worth noting that this approach to creating deb packages is not the most correct. Of course, in our case, we consciously take this step, but you need to understand that the deb package will contain all the contents of the project folder, including the src, vendor, and so on folders. Of course, you can copy files to another folder, and even write a script for this, but everything has already been invented before us. More the right way- this is to use the dh_make and dpkg-buildpackage utilities.

Now you can assemble the package. To do this, run the command one level higher:

Dpkg-deb -z8 -Zgzip --build project

One level up, a project.deb file will be created, which can be installed using the command:

Sudo dpkg -i project.deb

Your own package repository

Now let's get to the fun part. How do we distribute our packages? Let's launch our own repository server, of course. And for this we will use the apt repository server deb-simple.

This is a really simple server that can be installed with just one command:

Go get github.com/esell/deb-simple

If go is not installed on the machine where you are going to run the server with repositories, then you can build the binary locally and simply copy it. Alternatively, you can use docker.

Then you need to start the server. This can be done using docker, but I prefer to use supervisord. Here is an example of my service configuration:

Command=/home/user/go1.5/bin/deb-simple directory=/home/user/deb-simple/ autorestart=true stdout_logfile=none

Here it is important to indicate the path to the binary (command) and the working folder (directory) in which we will place our config.

The deb-simple server supports https, but we don't need it yet. For repositories, you need to create a repo folder. Our conf.json config will look like this:

( "listenPort" : "9090", "rootRepoPath" : "/home/user/deb-simple/repo", "supportedArch" : ["all","i386","amd64"], "enableSSL" : false, "SSLcert" : "server.crt", "SSLkey" : "server.key" )

To upload a package to your repository, you need to use the HTTP API of the service itself:

Curl -XPOST "http://localhost:9090/upload?arch=amd64" -F " [email protected]"

Likewise for deleting:

Curl -XDELETE "http://localhost:9090/delete" -d "("filename":"project.deb","arch":"amd64")"

All we have to do is add our repository server to the list in /etc/apt/source.list.d/ . You can create separate file with content:

Deb http://my-hostname:9090/ stable main

Now run sudo apt-get update and install your programs to your heart's content.

We'll tell you how to create the two most common types of Linux packages for distribution software, and you can distribute your own packages yourself.

We're going to walk you through the process of creating software packages for the two most popular package systems, DEB and RPM. You can use these techniques to package your own software, or even maintain packages for software that you feel is flying under the radar.

We'll start with a guide to creating DEB ((.deb) files for Debian-derived distributions - for this we use Xubuntu as our base. After that, we'll detail the techniques needed to create RPM packages for use on Red Hat-derived distributions , and we'll use Fedora for this. It's often possible to create a package on one distribution and then install it on a related distribution (eg Ubuntu>Debian), but if this is important, then you might want to try it yourself.

As for the program, we are going to use the lightweight web browser Dillo as an example package built from source code. When building from source, if the build does not work as expected, you can, as usual, search for solutions on the Internet. For example, in the case of Dillo 3.0.3, due to an oversight in the source code archive, we had to add "LIBS = -lX11" before the build commands in order for the commands to work.

The build takes place on the command line

Resources

Installation (or virtual machine) Ubuntu and Fedora

Step by step description

Step 01: Using a virtual machine

Using virtualization tools such as VirtualBox or Vmware is often the best approach to creating packages for other systems. On the one hand, this approach allows you to maintain a relatively clean base installation, comparable to the settings that others are likely to work with. This also means that you can get a collection of target systems using different distributions. Additionally, most virtualization tools allow you to emulate different architectures, and therefore a 32-bit platform can run 64-bit OSes, although performance will suffer.

Step 02: Let's start from scratch

If something goes wrong in Ubuntu or Fedora, it's perfectly safe to simply delete the source directory and start over. Note that the Debian tools modify the original archive, so you will have to start from a new copy.

Part 1: Debian

Step 03: Install the build environment

We'll start by installing most of the tools we need to create programs from source code. Dial:

$ sudo apt-get install build-essential autoconf automake autotools-dev

Now we need to install the tools that are used to work with DEB packages. Do this with the following command...

$ sudo apt-get install dh-make debhelper devscripts fakeroot xutils lintian pbuilder

Step 04: Create a GPG key

If you haven't created a GPG public key in the past, you need to create one now so that you can sign packages. First enter the text gpg –gen-key. Select the default values ​​and, when prompted, enter your real name and contact information. Carefully write down all the data, since later we will need to match them exactly in the configuration file. After this, type the command ls ~/.gnupg to make sure that the new key exists (this is the file firstname_lastname.gpg). Create a public key from it:

Gpg -a --output ~/.gnupg/.gpg --export "[your name]"

Import it with:

Gpg --import ~/.gnupg/.gpg

Step 05: Download the package

In this example, we are going to download and build the latest version of the Dillo web browser. Go to the Dillo website (www.dillo.org) and download the latest archive.tar.bz. Use the command mkdir ~/srcand to create a directory for the source code and move the archive into it.

Step 06: Unpack the archive

Unpack the archive using the command tar -xjvf [archive name].tar.bz2. Note that following directory naming conventions (packagename-version) is important for our purposes, and fortunately the Dillo package follows them. It is also important that the source code archive is one level above the source code directory.

Step 07: Configuring for Debian

Place the dh_make script in the newly unpacked directory, which will take care of most of the work - adding the configuration file and creating the directory structure, and which is part of the developer toolkit we added earlier.

Dh_make -e -c license -f ../

In our example, command line it will look like this:

Dh_make -c gpl3 -e [email protected]-f ../dillo-3.0.3.tar.bz2

When prompted, select one binary file. The script helper script must create a directory named Debian in the source code directory.

Step 08: Open control file

Open in text editor control file in the Debian subdirectory. Complete the Home Page section (use Google to complete a list of Debian program sections) and description fields for this file.

Step 09: Explore your existing dependencies

You can research what dependencies are required to run a program that comes as a package. Go to the directory with the source code and type the command dpkg-depcheck -d ./configure in the terminal. If you do this, you will receive errors indicating which package is missing that is required to build the program (supplied separately). You can open this package by typing sudo apt-get build-dep [package name], which should help if your distribution's repository supports the package. If it is not supported, you will have to repeatedly run dpkg-depcheck -d ./configur and add packages manually by typing psudo apt-get install [package name].

Step 10: Add dependencies to the control file

When all the steps from the previous step are completed, you should have a list of all the required packages. Add this list of dependencies to the depends: section of the control file. Items in the list must be separated by a comma and a space.

Try to complete this step as much as you can and don't skip it. Source: - this is usually home page project. In the Files section: * replace the copyright information with the names of the authors of the project. You can see an example of filling in the Files: debian/* section, in which the relevant information should be entered. You may have to be a bit of a detective to find the information you need. Look in the source directory for files such as AUTHORS and COPYING.

Step 12: Edit the change log file

Open the changelog file and make sure the name and address are email are the same as those you entered when creating the GPG key. Typically the helper script may add your username to the file rather than your real name. As with the copyright file, do not skip this section as it may cause the package creation process to stop or the wrong package to be created.

Step 13: Create a package

If everything is configured correctly, we can finally build the DEB package. Go to the source directory and run dpkg-buildpackage -b to build the package, which will be placed in the ~/src/ directory. For example, create a package using the dpkg -I [package] command. To check for compliance with Debian policies, run the Lintian program using the lintian [package] command. Please note that this tool is notoriously strict and it is up to you to decide whether some minor non-compliance warnings are acceptable to you. Finally, install the pact using the command sudo dpgk -i [package].

Part 2: Creating RPM Packages in Fedora

Step 14: Open control file

Switch to root user mode by typing su. Start with the Development Tools installation group in yum, and then use yum to install the gcc-c++ fedora- packager. Type the command usermod -a -G mock to add your user to the mock group. This allows us to perform the build procedure without having to become root.

Step 15: Create a build environment

Press Ctrl + D to exit the root role. Type rpmdev-setuptree to create the directory tree (under ~/rpmbuild) that we need.

Step 16: Download the archive and move it to the desired location

Download the Dillo package from the Dillo website and move the archive to the appropriate directory - type mv [archive name] ~/rpmbuild/SOURCES.

Step 17: Create a .spec file

Red Hat-based distributions, such as Fedora, use .spec files to specify the build process. Change to the directory containing such files using cd ~/rpmbuild/SPECS/andcreateablank.spec and create an empty .spec file using rpmdev-newspec dillo.

Step 18: Edit the .spec file

Type the command gedit dillo.spec. Fill in the Version, Summary, and License fields (in in this case- GPLv3+). The URL indicates home page project; Source0 specifies the address of the source code. Provide comments in the BuildRequires and Requires fields. Add full description to the %description area.

Step 19: Build the source code

If the package is supported at all on the system, run the yum-builddep [package name] command. IN otherwise, you will have to repeat the build command in order to receive error messages, or look for documentation in the source code archive. In the SPEC directory, type rpmbuild -ba[package name].spec. If this build fails and reports additional uncompressed files, highlight and copy this list of files to the %files section of the.spec file and reissue the build command. The package will now be located in the RPMS directory. Type rpm -ivh [package] to install it. Type the command rpm -qa | grep [package] to make sure it is installed.

This article is not complete. You can help write it

Correcting the style of the article

By adding more information about preparing source codes for debianization

Debian-based distributions not only have an excellent APT package management system that resolves dependencies itself, but also convenient tools for creating packages and their own repositories. If you have already decided to build a program from source code, then I advise you to also study how to debianize the source code. It will take a little longer than standard

but not all sources support this, and what is even more common is that the sources are deleted after installation, then the program can only be removed manually. But to do this, you need to know exactly what is installed and where. And no one knows this for sure, except the program developers themselves (well, or those who more or less understood the source code of the program).

Classification of assembly cases

Possible following cases package builds:

Build from source;

Assembly from binary files;

source codes or binary files are taken:

Not from the repository;

From the repository of another distribution;

From another Ubuntu release's repository, from a PPA, or from Debian;

debianization:

Not available;

Taken from the Ubuntu repository, from the PPA or from Debian:

• From another version of the program;

  From the current version of the program:

  • Not from the current Ubuntu release repository;

    From the current Ubuntu release repository;

reason for assembly:

Neither the current Ubuntu repository nor the PPA contains the required version of the program;

For some reason you are not satisfied with the available version of the program (you are not satisfied with the program code or data, configuration parameters or control information package);

Both.

Build from source

What is needed

The complete Beginner's Guide to Debian Developer is available.

Unfortunately, the information in Russian is a little outdated, the latest instructions are available in English. But the principles have not changed, so if you are interested in the details, it is better to read the manual thoroughly.

We will need at a minimum programs installed by the command

You can also autobook - this is documentation for the GNU utilities Autoconf, Automake, and Libtool. And of course, what they themselves require source codes for correct assembly.

Creating an Encryption Key

This step is optional and can be skipped.

To create a key, go to Applications → Accessories → Passwords and encryption keys. In the window that opens, in the menu Key → New key, select the key pgp. Filling out the fields Full name And Email address.

In the world of free software, to prevent “theft” or “counterfeiting”, it is customary to sign your “valuable” things electronic key, the public part of which is stored on public servers and allows other users to easily determine the authenticity and integrity of a particular thing.
Therefore, be very responsible when creating a key.
Nobody forces you to enter your real first and last name, or any other personal data here, but if you are not wanted by Interpol, I think entering your last name and first name will be the right decision, although you can just use your nickname. In general, decide for yourself. But please indicate the real mailing address, which you will not change.

You can create a box, if you don’t already have one, on some popular mail server: for example, gmail.com or yandex.ru.
This will make it easy for someone in the future to contact you who doesn’t know you, but for one reason or another came across a “thing” signed by you.
Next, you will be asked to enter a password as additional protection. It can be useful if you will be using the private key on machines that you cannot 100% trust. Reverse side- you will have to enter your password every time you sign something.

Although latest version programs seahorse has a daemon that automatically starts in a GNOME session, and can “remember the password” for the duration of the session, but not all programs can work with it yet.

So, you have created a key - now it can be used when creating packages.
To do this, in the file ~/.bashrc, or in another startup script of your favorite shell (for zsh ~/.zshrc), you need to enter variables

Export DEBEMAIL=your@email

Based on the e-mail, the key will be searched in pgp when signing the package.
You need to log out and log in again for the changes to take effect.
Remember that if you are backporting a package that you did not debianize, you must change the version with the command

so that your e-mail is included in the changes. And in order for your public key to get to the server, you need to “ seahorse→ Passwords and encryption keys”, set up a connection to the public key server.
To do this, in the menu Edit→Options on the bookmark Publication of keys you need to check the box Publish keys....
Now you can select the key in the menu by right button choose Sync and publish keys.

Debianization is not available

So we only have gcoolprog-0.5.3.tar.gz.

I usually do the following:

Pre-preparing the working directory

We receive the file gcoolprog-0.5.3.tar.gz. Let's unpack it and go to the resulting directory:

For correct assembly, the root directory must contain not only the name, but also the version!

If the command completed successfully, then all that remains is to debianize.

Debianization

There is nothing wrong with this, as I already said, there are scripts that greatly simplify this process.
In general, the point of this whole procedure is to create a debian directory in the root of the sources, with the necessary files configuration and script(s).
To do this, at the root of the source texts, we execute

Dh_make --createorig

What should we get the following dialogue for?

Type of package: single binary, multiple binary, library, kernel module or cdbs? s Maintainer name: denis Email-Address: [email protected] Date: Mon, 13 Aug 2007 12:40:33 +0400 Package Name: gcoolprog Version: 0.5.3 License: blank Type of Package: Single Hit to confirm:

Here we indicate to create a package for a single binary file.

But you and I are great and everything went without errors - a debian directory appeared in the root of the source code, looking at its contents, you will see a bunch of files (extension .ex) with examples for all occasions.

Description:

Instead of And (without corner quotes) you need to enter a description of what kind of program it is.
This is the information the user will see when they look at the package description.
The second point is to correct the file debian/rules
in section binary-arch: needs to be uncommented (i.e. remove the # at the beginning of the line)

Dh_install

without this we will get an empty packet.
Sometimes debian/rules contains only:

%:dh$@

What is acceptable using debhelper.
These settings will be sufficient to build a package with one program that does not contain shared libraries, i.e. only the binary in /usr/bin and data in /usr/share.

Building the package

Now, let's assemble the package:

In the directory above, i.e. in ~/src/gcoolprog/0.5.3, we will get the files

Gcoolprog_0.5.3-1.diff.gz gcoolprog_0.5.3-1_i386.changes gcoolprog_0.5.3-1_i386.deb gcoolprog_0.5.3.orig.tar.gz

Now we can install the package

Debianization is taken from the Ubuntu repository, from a PPA or from Debian

Debianization is taken from another version of the program

In this case, it is very convenient to take the debianization from there and correct it for the new version.

As I already said, perhaps we will be lucky and it will be enough to just change the version. But let's not guess.

Below I will not comment on what is described in the previous solution.

we get the file gcoolprog-0.5.3.tar.bz2

now let's unpack it

download previous version from http://packages.ubuntu.com or http://packages.debian.org, file gcoolprog_0.5.1.diff.gz(at the very bottom in the More Information on gcoolprog section)

we get the directory

copy the directory gcoolprog-0.5.1/debian to the directory ~/src/gcoolprog/0.5.3/gcoolprog-0.5.3

this command changes the debian/changelog file, for example we will see

Gcoolprog (0.5.1-1ubuntu2) feisty; urgency =low * -- denis< ubuntu_user@ mail.ru>

but since we have version 0.5.3, we need to change the values ​​to

Gcoolprog (0.5.3-1ubuntu1) feisty; urgency =low * New upstream release. --denis< ubuntu_user@ mail.ru>Mon, 13 Aug 2007 14:13:27 +0400

save changes. Now you can run the build command into a package.

Dpkg-buildpackage -rfakeroot

get the files

Debianization is taken from the current version of the program

Debianization is not taken from the repository of the current Ubuntu release

For Debian you need to use the site http://packages.debian.org, for Ubuntu - http://packages.ubuntu.com. Then, for example, in Ubuntu we look for the package gcoolprog in the repository for a future release.

Let's first prepare the working directory

now download three files

or the same thing, but with one command

Dget http:// archive.ubuntu.com/ ubuntu/ pool/ universe/ g/ gcoolprog/ gcoolprog_0.5.3-1 .dsc

from the package devscripts
then unpack with the command

Dpkg-source -x ./ gcoolprog_0.5.3-1 .dsc

We will get the directory gcoolprog-0.5.3. Let's go to it and change the version:

Now you can assemble the package

Dpkg-buildpackage -rfakeroot

get the files

Debianization is taken from the repository of the current Ubuntu release

In the case when there is a package for the desired version of the program in the repository of the current Ubuntu release, but for some reason it is not satisfactory and changes need to be made to its sources (for example, some patch must be applied) and rebuilt based on what is already in the package Debianization, you can do the following.

To build you will need the following packages: build-essential devscripts fakeroot. Development packages will also be required, we will install them later.

Download the sources:

apt-get source downloads sources from the Ubuntu repository into the current directory. Many packages in the repository have common sources with each other, so in addition to the sources of the selected package, the sources of other packages can also be downloaded (sources common to several packages).

Install the development packages required for assembly:

We collect packages:

debuild should be run in the source directory. The -b -us -uc options are passed to the dpkg-buildpackage program. The first requires collecting only binary packages, the second and third require not signing digital signature, respectively, the source package and the .changes file. The resulting packages will be in the directory one level higher.

Building from binary files

Below is an example of what you can do if only a deb package is available and there are no debianized sources.

Let's assume that we are working in a directory ~/tmp. Let's create a subdirectory ~/tmp/someprog to unpack the files of a package, you need to run

In order to extract control information, let's do

Well, now, in order to put it all back into the package, you need to do

In the catalog ~/tmp/someprog/DEBIAN contains files describing what the package is, what it depends on, and checksums files contained in it. In order to build your package, you need to place the files in the directory ~/tmp/someprog as if it were the root directory. That is, if you want the file to be installed in /usr/bin, you need to put it in the directory ~/tmp/someprog/usr/bin, and, accordingly, if something should be in /etc, then in ~/tmp/someprog/etc etc.

Then in ~/tmp/someprog create a directory DEBIAN, be sure to use capital letters, and in it a file ~/tmp/someprog/DEBIAN/control, this file describes the package name, its dependencies and description, the format is very simple. For example:

Package: libcurl3 Version: 7.15.2-2 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.5-1), libcomerr2 (>= 1.33-3), libidn11 (>= 0.5.18), libkrb53 (>= 1.4.2), libssl0.9.8 (>= 0.9.8a-1), zlib1g (>= 1:1.2.1), ca-certificates Suggests: libldap2 Replacements: libcurl2 (<< 1:7.11.2-2) Installed-Size: 324 Maintainer: Domenico Andreoli Source: curl Description: Multi-protocol file transfer library libcurl is designed to be a solid, usable, reliable and portable multi-protocol file transfer library. . SSL support is provided by OpenSSL. To enable LDAP support package libldap2-dev is required. . This is the shared version of libcurl. . Homepage: http://curl.haxx.se

Well, now assemble:

This information is enough to assemble/reassemble a simple package. In fact, you can also run scripts when installing a package, when uninstalling it, and much more that a normal maintainer needs.