Become a manager. Part two
On the second day, we already got used to the idea that Debian and Ubuntu love really free software and are already starting to think about how we would start to build our first package. But stop! And what programs do we know how to use? What?! OpenOffice.org Writer and Kopete? No, well, so it will not work. Today I will tell you the mandatory minimum that every future accompanying package will need (I decided to accept this term, leaving the overseas word “meinteiner” only in the title, as a tribute to the first article), and just any ubuntuser will come in handy in life.
(Parts 1 , 3 and 4 )
And we start with the GnuPG utility or just GPG. What it is? GPG is your ID, the ability to demonstrate on the Internet that you are hiding under your name, and not a malicious enemy, it is the ability to encrypt a mail or jabber message, it is the ability to sign the file, keeping the fingerprint in a separate file. Agree, it is much more reliable than a simple md5-hash - you also make it clear that you (and not someone else) saved the file (or files) in this state. In general, GPG is a very useful and necessary household tool. I will not tell all his opportunities, they can be read in mana, and I will tell only the most basic. So, we put the package in command
Now we need to create our own key pair. Typing
The standard key type (DSA and ElGamal) is fine with us, the standard size (2048 bits), too. The term of validity (without limitation) also suits the standard. Next we need to enter information about yourself. As an example, Debian offers: “Baba Yaga (pensioner) <yaga@deepforest.ru>”, where the information in brackets is a comment. It is not necessary for us to enter it, you can just restrict your name and e-mail:
If you enter the name and e-mail address specified for your login in / etc / passwd, then this key will by default be used to sign and encrypt everything that is possible.
Next we need to enter a password. Due to the fact that when signing a package, you will have to enter it more than once, I have often heard statements like “Yes, create a separate key without a password, it’s so secret, nobody will steal it from your laptop, and in general” . Do not fall for such provocations. Your gpg-key is your passport and more. To create a key without a password is the same as carrying a bag with a broken lightning bolt — even if we always keep it in front of us and cross the subway with running only at a run — why provoke potential thieves? Therefore, we come up with a complicated, memorable password, and finally we get a desired pair of keys:
Next we need to send our public key to some key server so that anyone can import it to himself:
Now anyone can enter the command
Now add two lines to your ~ / .bashrc:
Yes, now we will talk about the magic set of utilities APT and its use in the assembly packages. Unfortunately, many people are familiar with this package rather superficially, but how many problems could we have avoided.
First, remember the apt-key utility. It will be useful to us if we connect a third-party repository. This utility manages a list of trusted keys with which different repositories can be signed. If we execute the command
')
Go ahead. I promised to tell you why this approach is so terrible. Of course, if we were true Slackware users, holding all the installed packages with dozens of dependencies in mind, it would have been easy for us to compile and install another program from source (familiar Slackware users say that in recent versions there is even a complete package manager, perhaps even honestlycn ... stolen from Debian, but they still prefer to keep track of all dependencies manually in the old manner). But we all know what a package distribution is, dependencies, version control in the end. Putting pidgin into / opt / is uncivilized, even for the simple reason that once forgotten, we tap the pidgin button in the menu and launch the old version, with the broken ICQ.
“You can after all specify the prefix / usr /,” you say. Of course, the very first update package in the repository will rub your patched version. Who really needs it? No, we will do everything culturally. Since pidgin is a big, ugly and heavy package, and in general I don’t like it, I’ll tell you everything using the example of the ccache package that caches the compiler object files during build.
As is known, this package makes the files “gcc”, “g ++” and a few more similar files with symlinks to its executable file / usr / bin / ccache, while it itself looks at the name of the called file, according to which it substitutes the necessary compiler. But here's the problem - many sources when compiling refer to the file “c ++”, which should be a symlink to any suitable compiler, but the ccache does not know the “c ++” compiler. What to do? I decided not to suffer, not to retrain the source code and not to create unnecessary files, but to do with a dirty hack.
So, to work with source packages, we look at the /etc/apt/sources.list file. If we see there commented lines beginning with “deb-src”, we can safely comment them out, these are instructions on where to get the package files with source codes.
Now we take the cherished apt-get command familiar to us almost from childhood and execute it three times with different parameters:
Please note: the source package consists of three files: the .orig.tar.gz file is an archive with unchanged source codes - such as the developer of the program himself distributes them, the .diff.gz file is a diff file that contains all changes to the source code , including debian assembly instructions (about these instructions next time), and a .dsc file that stores brief information about the package, hashes of the first two files, and the dsc file itself is signed by the GPG signature of the package author. If desired, we could get the public key and verify this signature, but since we took the package from the official repository, we will not deal with such nonsense. Therefore, we go into the ccache-2.4 directory and, using our favorite text editor, change the file "
It is clear that most of you will never need this program and this patch, but at least the next time if you want to fix the package, for example, replace the icons in it with your favorites or add the line “Vasya here” to “About the program”, you will imagine what to do.
So, we fixed the source code, what should we do next? That's right, you need to increase the version number of the package. We type all in the same directory command
The “Non-maintainer upload” post was added automatically to show that this version of the package was created not by the maintainer of the package, but by an outsider. The proposed version number does not suit us, let's increase it and add a little bit of informativeness to the information about the changes. As a result, our record takes the following form:
Another way to install all the packages you need to build is:
All in the same directory ccache-2.4 type magic command
Is it convenient? Not only tell you what the error is, but also send to the appropriate section of the Debian developer documentation. Here I want to point out that in Debian the lintian utility is much stricter on packages than in Ubuntu, so if you want to get the perfect package, build it in Debian, and then port it into ubuntu, the mosquito doesn’t rub off. In this case, we were informed that our only mistake was that by deliberately changing the new version number offered to us, we changed it incorrectly. Now we will exit the directory one level higher and install the assembled package:
What is left for us? The most attentive reader who has read this far will surely ask himself: what if a new version of ccache is released, with a version number greater than 2.4-17? There are at least two solutions to this question. The first point in the build version is not 2.4-17, but obviously a large one, for example, 5.7-99. But such a decision once turned out to be ineffective when the proftpd patched by me suddenly replaced with a new version, which finally reached the number I specified. The second solution is a little more elegant. We collect:
This article actually had to be even more, but due to the late (or even already early) time, as well as the rather large volume of what I already typed, to highlight everything I wanted was not possible. I decided to drop at least a story about the sed and awk commands, hoping that you would master them if necessary.
What is still behind the scenes? Create a repository of the packages you have collected. This story will take more than a few lines, so he stayed the next time.
Maybe someone else will say that the above way to patch a package is also not true, and it will be absolutely right. If we think about the fact that we have to go through the same procedure of editing files if we want to patch a new version of the package, it becomes clear that our method is only suitable for quick editing - for example, if the developers promised to correct the pidgin in the new version, and we we want to apply it now. For fixes on an ongoing basis, we will use the diff and dpatch utilities. But I suggest you to master them yourself as a homework, as well as independently assemble the corrected pidgin package for your needs. Leave your wishes, what would you like to know, I will try in the following parts to illuminate as much as possible.
(Parts 1 , 3 and 4 )
GPG
And we start with the GnuPG utility or just GPG. What it is? GPG is your ID, the ability to demonstrate on the Internet that you are hiding under your name, and not a malicious enemy, it is the ability to encrypt a mail or jabber message, it is the ability to sign the file, keeping the fingerprint in a separate file. Agree, it is much more reliable than a simple md5-hash - you also make it clear that you (and not someone else) saved the file (or files) in this state. In general, GPG is a very useful and necessary household tool. I will not tell all his opportunities, they can be read in mana, and I will tell only the most basic. So, we put the package in command
$ sudo apt-get install gnupgNow we need to create our own key pair. Typing
$ gpg --gen-keyThe standard key type (DSA and ElGamal) is fine with us, the standard size (2048 bits), too. The term of validity (without limitation) also suits the standard. Next we need to enter information about yourself. As an example, Debian offers: “Baba Yaga (pensioner) <yaga@deepforest.ru>”, where the information in brackets is a comment. It is not necessary for us to enter it, you can just restrict your name and e-mail:
: Ivan Ivanov
Email-: ivan@ivanov.iv
:
User ID:
"Ivan Ivanov <ivan@ivanov.iv>"If you enter the name and e-mail address specified for your login in / etc / passwd, then this key will by default be used to sign and encrypt everything that is possible.
Next we need to enter a password. Due to the fact that when signing a package, you will have to enter it more than once, I have often heard statements like “Yes, create a separate key without a password, it’s so secret, nobody will steal it from your laptop, and in general” . Do not fall for such provocations. Your gpg-key is your passport and more. To create a key without a password is the same as carrying a bag with a broken lightning bolt — even if we always keep it in front of us and cross the subway with running only at a run — why provoke potential thieves? Therefore, we come up with a complicated, memorable password, and finally we get a desired pair of keys:
$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
----------------------------------
pub 1024D/3904FAE7 2009-01-30
uid Ivan Ivanov <ivan@ivanov.iv>
sub 2048g/2DA010F1 2009-01-30Next we need to send our public key to some key server so that anyone can import it to himself:
$ gpg --keyserver subkeys.pgp.net --send-keys 3904FAE7
gpg: 3904FAE7 hkp subkeys.pgp.netNow anyone can enter the command
$ gpg --keyserver subkeys.pgp.net --recv-keys 3904FAE7Now add two lines to your ~ / .bashrc:
export DEBFULLNAME="Ivan Ivanov"
export DEBEMAIL="ivan@ivanov.iv"Apt
Yes, now we will talk about the magic set of utilities APT and its use in the assembly packages. Unfortunately, many people are familiar with this package rather superficially, but how many problems could we have avoided.
First, remember the apt-key utility. It will be useful to us if we connect a third-party repository. This utility manages a list of trusted keys with which different repositories can be signed. If we execute the command
$ sudo apt-key list$ wget -O - qutim.org/debian/archive.key | sudo apt-key add -')
Go ahead. I promised to tell you why this approach is so terrible. Of course, if we were true Slackware users, holding all the installed packages with dozens of dependencies in mind, it would have been easy for us to compile and install another program from source (familiar Slackware users say that in recent versions there is even a complete package manager, perhaps even honestly
“You can after all specify the prefix / usr /,” you say. Of course, the very first update package in the repository will rub your patched version. Who really needs it? No, we will do everything culturally. Since pidgin is a big, ugly and heavy package, and in general I don’t like it, I’ll tell you everything using the example of the ccache package that caches the compiler object files during build.
As is known, this package makes the files “gcc”, “g ++” and a few more similar files with symlinks to its executable file / usr / bin / ccache, while it itself looks at the name of the called file, according to which it substitutes the necessary compiler. But here's the problem - many sources when compiling refer to the file “c ++”, which should be a symlink to any suitable compiler, but the ccache does not know the “c ++” compiler. What to do? I decided not to suffer, not to retrain the source code and not to create unnecessary files, but to do with a dirty hack.
So, to work with source packages, we look at the /etc/apt/sources.list file. If we see there commented lines beginning with “deb-src”, we can safely comment them out, these are instructions on where to get the package files with source codes.
Now we take the cherished apt-get command familiar to us almost from childhood and execute it three times with different parameters:
$ sudo apt-get update
$ sudo apt-get install devscripts lintian
$ apt-get source ccache:1 http.us.debian.org sid/main ccache 2.4-16 (dsc) [1118B]
:2 http.us.debian.org sid/main ccache 2.4-16 (tar) [86,4kB]
:3 http.us.debian.org sid/main ccache 2.4-16 (diff) [44,1kB]
132k 2s (51,1k/c)
dpkg-source: ccache ccache-2.4
dpkg-source: : ccache_2.4.orig.tar.gz
dpkg-source: : ccache_2.4-16.diff.gzPlease note: the source package consists of three files: the .orig.tar.gz file is an archive with unchanged source codes - such as the developer of the program himself distributes them, the .diff.gz file is a diff file that contains all changes to the source code , including debian assembly instructions (about these instructions next time), and a .dsc file that stores brief information about the package, hashes of the first two files, and the dsc file itself is signed by the GPG signature of the package author. If desired, we could get the public key and verify this signature, but since we took the package from the official repository, we will not deal with such nonsense. Therefore, we go into the ccache-2.4 directory and, using our favorite text editor, change the file "
x_asprintf(&fname, "%s/%s", tok, name); " in the execute.c file x_asprintf(&fname, "%s/%s", tok, name); "to the lines:if (strcmp(name, "c++") == 0) {
x_asprintf(&fname, "%s/%s", tok, "g++");
} else {
x_asprintf(&fname, "%s/%s", tok, name);
}It is clear that most of you will never need this program and this patch, but at least the next time if you want to fix the package, for example, replace the icons in it with your favorites or add the line “Vasya here” to “About the program”, you will imagine what to do.
So, we fixed the source code, what should we do next? That's right, you need to increase the version number of the package. We type all in the same directory command
$ dch -iccache (2.4-16.1) unstable; urgency=low
* Non-maintainer upload.
*
-- Vsevolod Velichko <torkvemada@nigma.ru> Fri, 30 Jan 2009 06:05:36 +0300The “Non-maintainer upload” post was added automatically to show that this version of the package was created not by the maintainer of the package, but by an outsider. The proposed version number does not suit us, let's increase it and add a little bit of informativeness to the information about the changes. As a result, our record takes the following form:
ccache (2.4-17) unstable; urgency=low
* Non-maintainer upload
* Patched for the "c++" as compiler name support
-- Vsevolod Velichko <torkvemada@nigma.ru> Fri, 30 Jan 2009 06:05:36 +0300Build-Depends: debhelper (>> 6), autotools-dev, zlib1g-devIt lists which packages, besides the standard ones, will be required to build the package. We recruit for warranty:
$ sudo apt-get install debhelper autotools-dev zlib1g-devAnother way to install all the packages you need to build is:
$ sudo apt-get build-dep ccacheAll in the same directory ccache-2.4 type magic command
$ debuild --lintian-opts -iNow running lintian ...
W: ccache source: source-nmu-has-incorrect-version-number 2.4-17
N:
N: A source NMU should have a Debian revision of "-xx" (or "+ nmuX" for a
N: native package). This is to prevent stealing version numbers from the
N: maintainer.
N:
N: Maybe you didn’t intend this upload to be a NMU, in that case, please
N: doublecheck thats most recent entry in the changelog is byte-for-byte
N: identical to the maintainer or one of the uploaders. If this is a local
N: package (not intended for Debian), you can suppress this warning by
N: putting "local" in the version number or "local package" on the first
N: line of the changelog entry.
N:
N: Refer to Debian Developer's Reference section 5.11.2 (NMU version
N: numbering) for details.
N:
N: Severity: normal; Certainty: certain
N:
Is it convenient? Not only tell you what the error is, but also send to the appropriate section of the Debian developer documentation. Here I want to point out that in Debian the lintian utility is much stricter on packages than in Ubuntu, so if you want to get the perfect package, build it in Debian, and then port it into ubuntu, the mosquito doesn’t rub off. In this case, we were informed that our only mistake was that by deliberately changing the new version number offered to us, we changed it incorrectly. Now we will exit the directory one level higher and install the assembled package:
$ sudo dpkg -i ccache_2.4-17_amd64.debWhat is left for us? The most attentive reader who has read this far will surely ask himself: what if a new version of ccache is released, with a version number greater than 2.4-17? There are at least two solutions to this question. The first point in the build version is not 2.4-17, but obviously a large one, for example, 5.7-99. But such a decision once turned out to be ineffective when the proftpd patched by me suddenly replaced with a new version, which finally reached the number I specified. The second solution is a little more elegant. We collect:
$ sudo aptitude hold ccacheTotal
This article actually had to be even more, but due to the late (or even already early) time, as well as the rather large volume of what I already typed, to highlight everything I wanted was not possible. I decided to drop at least a story about the sed and awk commands, hoping that you would master them if necessary.
What is still behind the scenes? Create a repository of the packages you have collected. This story will take more than a few lines, so he stayed the next time.
Maybe someone else will say that the above way to patch a package is also not true, and it will be absolutely right. If we think about the fact that we have to go through the same procedure of editing files if we want to patch a new version of the package, it becomes clear that our method is only suitable for quick editing - for example, if the developers promised to correct the pidgin in the new version, and we we want to apply it now. For fixes on an ongoing basis, we will use the diff and dpatch utilities. But I suggest you to master them yourself as a homework, as well as independently assemble the corrected pidgin package for your needs. Leave your wishes, what would you like to know, I will try in the following parts to illuminate as much as possible.
Source: https://habr.com/ru/post/50631/
All Articles