Become a manager. Part three
And there was a third day, and the habriol user, ubuntoid, thought: how can I pack my favorite package so that it is beautiful and correct and so that its kosher pride is bursting with hoo how. This is what we are going to do today.
(Parts 1 , 2 and 4 )
At the initiative of darkk, we will assemble a package of redsocks , which in Russian means “dark socks of darkk”.
First of all, follow the link mentioned above and download the archive with source codes. I do not know about you, but my name is “darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz”. You understand that an archive with such a name is not good. Therefore, we first unpack it and erase it:
Now we have a directory called "darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64". Also worthless. Fortunately, for extreme cases, for example, here such, when the program has no normal versions at all, Debian allows you to change the numbering. This is what we will do now:
We will rename the directory with the first action: now the version will be numbered by date plus the version number for the current date - this time the version will be 01. The second is creating a “kosher” source archive. Note, by the way, that the directory should be named as “name-version” by rules, and the archive as “name_version.orig.tar.gz”. In the first case, a hyphen should precede the version, in the second - an underscore.
Now, oddly enough, if you are familiar with the program as much as I do (that is, you see it for the first time in your life), then install the libevent-dev package, which is specified in the program’s dependencies, and without any frills we try to build our program:
Personally, I have this procedure dropped with an error:
And here comes into force one of the first commandments accompanying the package: either you very closely come into contact with the author of the upstream, or you become a major Internet search specialist. This time, out of pride, I preferred the second option and, through a thorough search, found that the bug is old. manifested itself already for half a year and for some reason they do not hurry to fix it But the local fix in the package can be made and we will make it now (small note: I again do not draw up a separate patch, but correct it right in the code, because a cultural person must send such severe errors to the upstream author and kick him with the legs It will not be included in the Upstream. If it is not, see such authors of the programs. So, in the meantime, we are in the base.c file before the line
We collect again. Error again:
Again we climb into the search, we do not detect anything (at least I), but we understand with a monstrous telepathic effort that the event_loopbreak method that we have in the libevent repository still does not know how. Okay, we say, what do we do? The new version in debian is only in experimental repository. Personally, I did not dare to connect it. Therefore, we perform the following actions:
I explain. Since we do not want to connect a repository to ourselves, in which a sea of ​​terribly unstable software, we delete the libevent we have and assemble the initial package of the new version, which we downloaded using the dget command. Now that we have successfully installed the assembled package, we will try to assemble our red socks again:
This time I got everything together successfully. Wonderful. Now look at our directory, try to understand what files should be assembled into the final binary package that the user will put on his computer. Personally, I have highlighted this set:
Great, now let's try a few options.
Yes, in other words it is difficult to call it, so I have to call it that way.
Attention, this version of the assembly is presented solely for information and those who use it should be executed seven times in accordance with the laws of the country of Oz!
So, we create in our directory with the collected program, another directory "darkk-redsocks-2009013101". Copy the files into it so that the following hierarchy is obtained:
Create a directory darkk-redsocks-2009013101 / DEBIAN and put the control file with the following contents into it:
Since we still have to work with the control files, I will immediately give a little bit of explanation. This file stores the entire description of the package - for what architecture it is assembled, who is its maintainer, etc. In principle, everything is clear, only the Description item is of interest. It is arranged in a sly way: in the first line, immediately after the word “Description:” a short description is written. Writing it by the rules is necessary so that it can be substituted into the line " Packagename is a description ". That is, it is written with a small letter, without the subject and the word "is" (with a possible article), does not contain any punctuation mark at the end. In this case, the brief description should not mention the name of the package, and it should fit into one sentence and be no longer than 60 characters. Starting with the next line is a complete description of the package. Each line in the description should again be no longer than 80 characters (by the way, this is a general requirement, including for all sorts of scripts) and start with a space. If you want to insert an empty line in the description, put a space and a dot on it. Well, in the good tradition of Debian, the file should end with an empty line.
Ok, with the control file done away. After we saved it, we assemble our package with the command
In this case, darkk-redsocks-2009013101 is the name of our directory, into which we have stuffed the files for the package, and in combination, it will also be the name of the received deb-package. Enjoy the spectacle? Now we urgently recruit
And so, we are again in a situation where we have collected binaries and nothing else. Let's fix this situation. We collect:
We happily cleaned the directory from both the binary and the object files from everything that was generated during the build. Now we type
In an amicable way, the watch file would not hurt us, but since we have no normal, anywhere laid out releases that we can follow, but only a git repository, we will not need it. Now open the control file, erase everything from it and write new, beautiful content:
Here, in principle, everything is clear, except for a couple of moments. First comes the description of the source package, then, through the empty line - the binary package. "Architecture: any" means in this case that you can substitute any architecture into the compiled binary package - under what we collect it will be substituted. If we collected, for example, a dev-package, which is the same for all architectures, we would write there: “all”. Sometimes it is necessary that one src package compiles several binary packages, for example, qutIM that I repeatedly mention is collected - its source code provides not only the program itself, which is built into the qutim package, but also the header files for potential plugins - we have to put them in the qutim-dev package. In such cases, we write descriptions of several collected binary packages in a row in the control file, separating them with empty lines. Now - section Build-Depends. First, it does not need to specify the compiler, make, etc. If you don’t have any miracles, install the build-essential package, and if it’s already there, open the file / usr / share / doc / build-essential / list, which contains a list of packages that you never need to specify in dependencies to build. Next is the debhelper package. This is a package that gives us a lot of joy to build, it depends on its version how cool the buns we can use. I recommend leaving the seventh version, because you will be able to enjoy its buns when we write a script for the assembly. Well, libevent-dev, the package with which we used to suffer so much. Required - with the version.
We go further. Open the compat file, compare it with the number standing there - it should be the same as the debhelper version in the control file, that is, 7. Why you need it - honestly, I don’t know, but it’s lazy to figure out. But need :)
Open the changelog file and bring it to the following form:
Notice, we changed the release on experimental (for ubuntu, I suspect, we need to put something like jaunty there), since we can take the necessary version of libevent-dev only there (actually, we downloaded it from there). The phrase “Closes: # 123456” is needed in order for the debian or ubunt bugtracking system when adding a package to the repository to automatically close the bug with the corresponding number. In the case of initial packaging, as we have - this is the “bug” of package creation planning - ITP (intend to package). Since we didn’t have such a bug, we’ll put an arbitrary number there until we’re going to include the package in the official repository. In the future, we will update the changelog using the “dch” utility already mentioned in the last article, executing the “dch -i” command.
Now go to the file copyright. It is already filled with a standard template, we have to fill in the details. We bring him to this form:
But then we start editing the files that, when creating a package, the magic package debhelper will process for us. First of all, the docs file. It contains a list of files that need to be installed in the documentation directory. In the general case, when our src-package creates only one binary package when building - this file can be left with the name docs. But we, in order not to mess around in the future, immediately rename it by the name of the binary package:
Now open it and add all our documentation there:
The next item on the program is the sample file. For it, we create the file darkk-redsocks.examples and write to it:
Since our Makefile does not know how to install the package, we also create the darkk-redsocks.install file. In it, we write the following entry:
Files described? Wonderful, we just need to edit the last file. Open the rules file in the editor and begin to root it mercilessly. Well, we don’t need the configure section, we don’t know how to source it - we delete it and all references to it. The remaining file is brought to this elegant look:
Note: in the source file, all calls looked like “dh_everything”, for example, “dh_install”. These are debhelper's atomic reactions that you can read about in the appropriate mana. We use commands like “dh install” when the call goes to the dh utility (also see the corresponding man). This utility calls each script in turn from a specific group to which the passed parameter points. Thus, while we have a fairly simple package, most of these calls will run idle during assembly, but then, as soon as we add a mana page to the package, it will suffice to create the darkk-redsocks.manpages file, specify this page there, and at the next build dh he will put it where necessary, and the script registering this page in mandb will add it.
So, we are done with editing the files. We exit the debian directory into the parent directory and with a feeling of deep satisfaction we type:
At the request of the password, we sign our resulting src-package, and then carefully look. The directory above we now have a set of files:
Someone might think that everything, this work is complete. If you are really lucky, then yes. In practice, this is where the simple and general part ends, and individual disassembly begins with each person with their own package. Well, you squandered your terminal back to the package building process. Who has already run away at all - you can open the newly-collected darkk-redsocks_2009013101-1_amd64.build file (you will, of course, have your own architecture instead of amd64), and see what the lintian stern censor says:
And he tells us that there is no manual page for the binary. As it is known, decent people should provide every binary with at least a simple mana describing what it is. And we have something in the package and it is not. there are always two ways out: the first is to ask the author of the program to write a manus The second is to write a mana and either ask the author to add it to the program, or put it in the package himself, pointing himself in copyrights.
But on the whole, then only changes are left to us from the work on the package, and if you want to correct something, a thoughtful reading of the Debian Policy .
The largest and most frequent stone is license purity. My friends, you just can not imagine how many people have run into it. You take the program, compile it into a package, and debian-legal says to you: “guy, and you generally know that the src / face / ob / table.cpp file is taken from another program, and you did not specify it in copyrights ? And the entire contents of the src / super / karambol / directory is generally distributed under a non-free license. Ah ah ah". But suppose you corrected an error, somehow miraculously persuaded the author of the program to write a free analog instead of a non-free code, and your package was included in the repository. But after a week, a meticulous user discovers: “dude, how can that be. They have here in the messenger client icons are displayed. And each logo is always distributed under the license of its program. So you do not have the right to archive the icon of a non-free ICQ 6.5 client. ” Of course, with these words, debian-legal frowns and with an accurate kick kicks your already received package out of the repository. That is why, by the way (I promised to tell you), qutIM's package was condescendingly taken into ubuntu, and I'm not even trying to get into Debian with him until all licensing issues are resolved. For the only non-free icons I will drive slippers through the entire community.
Another extremely important issue is, oddly enough, the authors of the programs. Pray for the author whom you will easily convince to accept corrections, additions or something else upstream. Because such authors are very rare. Take, for example, Pidgin's src-package, admire. It contains a large bundle of patches from the debian community. Upstream pidgin does not take them. And if you try to bring something good into Gnome ... they say, even Thorvalds did it with difficulty.
Sometimes you may be shown some kind of incorrect placement of directories or the absence or incorrect size / format of some icon for a shortcut to a program in sneakers - lintian likes to swear at it, and you should listen to it first. But these are all fairly easily fixable bugs, but the first two problems are really serious and durable.
At this point, I say goodbye to you for a few days, next time I will tell you how to create your own repository and, if I have time, how to check your kosher packages using pbuilder.
(Parts 1 , 2 and 4 )
At the initiative of darkk, we will assemble a package of redsocks , which in Russian means “dark socks of darkk”.
First of all, follow the link mentioned above and download the archive with source codes. I do not know about you, but my name is “darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz”. You understand that an archive with such a name is not good. Therefore, we first unpack it and erase it:
$ tar xvf darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz
$ rm darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gzNow we have a directory called "darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64". Also worthless. Fortunately, for extreme cases, for example, here such, when the program has no normal versions at all, Debian allows you to change the numbering. This is what we will do now:
$ mv darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64 darkk-redsocks-2009013101
$ tar czf darkk-redsocks_2009013101.orig.tar.gz darkk-redsocks-2009013101We will rename the directory with the first action: now the version will be numbered by date plus the version number for the current date - this time the version will be 01. The second is creating a “kosher” source archive. Note, by the way, that the directory should be named as “name-version” by rules, and the archive as “name_version.orig.tar.gz”. In the first case, a hyphen should precede the version, in the second - an underscore.
Now, oddly enough, if you are familiar with the program as much as I do (that is, you see it for the first time in your life), then install the libevent-dev package, which is specified in the program’s dependencies, and without any frills we try to build our program:
$ sudo apt-get install libevent-dev
$ cd darkk-redsocks-2009013101
$ makePersonally, I have this procedure dropped with an error:
cc -std = gnu99 -Wall -g -O0 -c base.c -o base.o
In file included from /usr/include/linux/netfilter_ipv4.h:8,
from base.c: 29:
/usr/include/linux/netfilter.h:44: error: field 'in' has incomplete type
/usr/include/linux/netfilter.h:45: error: field 'in6' has incomplete type
make: *** [base.o] Error 1
And here comes into force one of the first commandments accompanying the package: either you very closely come into contact with the author of the upstream, or you become a major Internet search specialist. This time, out of pride, I preferred the second option and, through a thorough search, found that the bug is old. manifested itself already for half a year and for some reason they do not hurry to fix it But the local fix in the package can be made and we will make it now (small note: I again do not draw up a separate patch, but correct it right in the code, because a cultural person must send such severe errors to the upstream author and kick him with the legs It will not be included in the Upstream. If it is not, see such authors of the programs. So, in the meantime, we are in the base.c file before the line
# include <linux/netfilter_ipv4.h># include <netinet/in.h>We collect again. Error again:
cc parser.o main.o redsocks.o log.o http-connect.o socks4.o socks5.o http-relay.o base.o -levent -o redsocks
main.o: In function terminate:
/home/user/build/darkk-redsocks-2009013101/main.c:44: undefined reference to `event_loopbreak '
Again we climb into the search, we do not detect anything (at least I), but we understand with a monstrous telepathic effort that the event_loopbreak method that we have in the libevent repository still does not know how. Okay, we say, what do we do? The new version in debian is only in experimental repository. Personally, I did not dare to connect it. Therefore, we perform the following actions:
$ cd ..
$ sudo apt-get --purge remove libevent1 libevent-dev
$ dget http://ftp.de.debian.org/debian/pool/main/libe/libevent/libevent_1.4.8~stable-1.dsc
$ cd libevent-1.4.8~stable/
$ debuild
$ cd ..
$ sudo dpkg -i ./libevent*.debI explain. Since we do not want to connect a repository to ourselves, in which a sea of ​​terribly unstable software, we delete the libevent we have and assemble the initial package of the new version, which we downloaded using the dget command. Now that we have successfully installed the assembled package, we will try to assemble our red socks again:
$ cd darkk-redsocks-2009013101/
$ makeThis time I got everything together successfully. Wonderful. Now look at our directory, try to understand what files should be assembled into the final binary package that the user will put on his computer. Personally, I have highlighted this set:
doc / * - documentation
README - the same
redsocks.conf.example - sample file
redsocks - the executable file itself
Great, now let's try a few options.
Let's make a govnopack of ready-made binaries
Yes, in other words it is difficult to call it, so I have to call it that way.
Attention, this version of the assembly is presented solely for information and those who use it should be executed seven times in accordance with the laws of the country of Oz!
So, we create in our directory with the collected program, another directory "darkk-redsocks-2009013101". Copy the files into it so that the following hierarchy is obtained:
darkk-redsocks-2009013101/
|-usr/
.|-bin/
.||-redsocks
.|-share/
..|-doc/
...|-redsocks/
....|-COPYING
....|-README
....|-rfc1929-socks5-auth.txt
....|-rfc2817-http-connect.txt
....|-socks4a.protocol.txt
....|-rfc1928-socks5.txt
....|-rfc1961-socks5-gssapi.txt
....|-rfc3089-socks-ipv6.txt
....|-socks4.protocol.txt
....|-examples/
.....|-redsocks.conf.exampleCreate a directory darkk-redsocks-2009013101 / DEBIAN and put the control file with the following contents into it:
Package: darkk-redsocks
Version: 2009013101
Architecture: amd64
Maintainer: Ivan Ivanov <ivan@ivanov.iv>
Description: transparent redirector of any TCP connection to proxy
Mega-package which TCP connection to redirects
damn proxy.
Since we still have to work with the control files, I will immediately give a little bit of explanation. This file stores the entire description of the package - for what architecture it is assembled, who is its maintainer, etc. In principle, everything is clear, only the Description item is of interest. It is arranged in a sly way: in the first line, immediately after the word “Description:” a short description is written. Writing it by the rules is necessary so that it can be substituted into the line " Packagename is a description ". That is, it is written with a small letter, without the subject and the word "is" (with a possible article), does not contain any punctuation mark at the end. In this case, the brief description should not mention the name of the package, and it should fit into one sentence and be no longer than 60 characters. Starting with the next line is a complete description of the package. Each line in the description should again be no longer than 80 characters (by the way, this is a general requirement, including for all sorts of scripts) and start with a space. If you want to insert an empty line in the description, put a space and a dot on it. Well, in the good tradition of Debian, the file should end with an empty line.
Ok, with the control file done away. After we saved it, we assemble our package with the command
$ dpkg -b darkk-redsocks-2009013101In this case, darkk-redsocks-2009013101 is the name of our directory, into which we have stuffed the files for the package, and in combination, it will also be the name of the received deb-package. Enjoy the spectacle? Now we urgently recruit
$ rm -rf darkk-redsocks-2009013101 darkk-redsocks-2009013101.debPutting the package as cultural people
And so, we are again in a situation where we have collected binaries and nothing else. Let's fix this situation. We collect:
$ make distcleanWe happily cleaned the directory from both the binary and the object files from everything that was generated during the build. Now we type
$ dh_makechangelog
compat
control
copyright
docs
rules
In an amicable way, the watch file would not hurt us, but since we have no normal, anywhere laid out releases that we can follow, but only a git repository, we will not need it. Now open the control file, erase everything from it and write new, beautiful content:
Source: darkk-redsocks
Section: net
Priority: optional
Homepage: http://darkk.net.ru/redsocks
Maintainer: Vsevolod Velichko <torkvemada@nigma.ru>
Build-Depends: debhelper(>=7), libevent-dev(>=1.4.2)
Standards-Version: 3.8.0
Vcs-Git: git://github.com/darkk/redsocks.git
Vcs-Browser: http://github.com/darkk/redsocks/tree/master
Package: darkk-redsocks
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: transparent redirector of any TCP connection to proxy
Mega-package which redirects any TCP connections to somewhat
damn proxy.
Here, in principle, everything is clear, except for a couple of moments. First comes the description of the source package, then, through the empty line - the binary package. "Architecture: any" means in this case that you can substitute any architecture into the compiled binary package - under what we collect it will be substituted. If we collected, for example, a dev-package, which is the same for all architectures, we would write there: “all”. Sometimes it is necessary that one src package compiles several binary packages, for example, qutIM that I repeatedly mention is collected - its source code provides not only the program itself, which is built into the qutim package, but also the header files for potential plugins - we have to put them in the qutim-dev package. In such cases, we write descriptions of several collected binary packages in a row in the control file, separating them with empty lines. Now - section Build-Depends. First, it does not need to specify the compiler, make, etc. If you don’t have any miracles, install the build-essential package, and if it’s already there, open the file / usr / share / doc / build-essential / list, which contains a list of packages that you never need to specify in dependencies to build. Next is the debhelper package. This is a package that gives us a lot of joy to build, it depends on its version how cool the buns we can use. I recommend leaving the seventh version, because you will be able to enjoy its buns when we write a script for the assembly. Well, libevent-dev, the package with which we used to suffer so much. Required - with the version.
We go further. Open the compat file, compare it with the number standing there - it should be the same as the debhelper version in the control file, that is, 7. Why you need it - honestly, I don’t know, but it’s lazy to figure out. But need :)
Open the changelog file and bring it to the following form:
darkk-redsocks (2009013101-1) experimental; urgency=low
* Initial release (Closes: #123456)
-- Vsevolod Velichko <torkvemada@nigma.ru> Sat, 31 Jan 2009 04:07:47 +0300Notice, we changed the release on experimental (for ubuntu, I suspect, we need to put something like jaunty there), since we can take the necessary version of libevent-dev only there (actually, we downloaded it from there). The phrase “Closes: # 123456” is needed in order for the debian or ubunt bugtracking system when adding a package to the repository to automatically close the bug with the corresponding number. In the case of initial packaging, as we have - this is the “bug” of package creation planning - ITP (intend to package). Since we didn’t have such a bug, we’ll put an arbitrary number there until we’re going to include the package in the official repository. In the future, we will update the changelog using the “dch” utility already mentioned in the last article, executing the “dch -i” command.
Now go to the file copyright. It is already filled with a standard template, we have to fill in the details. We bring him to this form:
This package was debianized by Vsevolod Velichko <torkvemada@nigma.ru> on
Sat, Jan. 31, 2009 04:07:47 +0300.
')
It was downloaded from http://darkk.net.ru/redsocks/
Upstream Author:
Leonid Evdokimov <leon@darkk.net.ru>
Copyright:
Copyright © 2009 Leonid Evdokimov
License:
This program is free software: you can redistribute it and / or modify
it published under the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
It will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see < http://www.gnu.org/licenses/ >.
The Debian packaging is copyright 2009, Vsevolod Velichko <torkvemada@nigma.ru> and
is licensed under the GPL, see `/ usr / share / common-licenses / GPL '.
But then we start editing the files that, when creating a package, the magic package debhelper will process for us. First of all, the docs file. It contains a list of files that need to be installed in the documentation directory. In the general case, when our src-package creates only one binary package when building - this file can be left with the name docs. But we, in order not to mess around in the future, immediately rename it by the name of the binary package:
$ mv docs darkk-redsocks.docsNow open it and add all our documentation there:
README
doc / *
The next item on the program is the sample file. For it, we create the file darkk-redsocks.examples and write to it:
redsocks.conf.example
Since our Makefile does not know how to install the package, we also create the darkk-redsocks.install file. In it, we write the following entry:
redsocks usr / bin /Note that there is no slash before usr.
Files described? Wonderful, we just need to edit the last file. Open the rules file in the editor and begin to root it mercilessly. Well, we don’t need the configure section, we don’t know how to source it - we delete it and all references to it. The remaining file is brought to this elegant look:
#! / usr / bin / make -f
# - * - makefile - * -
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE = 1
build: build-stamp
build-stamp:
dh build
touch $ @
clean:
dh clean
install: build
dh install
touch $ @
binary-indep: install
dh binary-indep
binary-arch: install
dh binary-arch
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
Note: in the source file, all calls looked like “dh_everything”, for example, “dh_install”. These are debhelper's atomic reactions that you can read about in the appropriate mana. We use commands like “dh install” when the call goes to the dh utility (also see the corresponding man). This utility calls each script in turn from a specific group to which the passed parameter points. Thus, while we have a fairly simple package, most of these calls will run idle during assembly, but then, as soon as we add a mana page to the package, it will suffice to create the darkk-redsocks.manpages file, specify this page there, and at the next build dh he will put it where necessary, and the script registering this page in mandb will add it.
So, we are done with editing the files. We exit the debian directory into the parent directory and with a feeling of deep satisfaction we type:
$ debuild --lintian-opts -iAt the request of the password, we sign our resulting src-package, and then carefully look. The directory above we now have a set of files:
darkk-redsocks_2009013101-1_amd64.build is a log containing the entire build process of the package.
darkk-redsocks_2009013101-1_amd64.changes is an auxiliary file for the src-package
darkk-redsocks_2009013101-1_amd64.deb - the actual package itself for our architecture
darkk-redsocks_2009013101-1.diff.gz is a packed diff file in which all our changes are stored compared to the original sources. As a rule, these are all the contents of the debian directory, and in our case, remember the corrected base.c file?
darkk-redsocks_2009013101-1.dsc - this is the main file description of the src-package
darkk-redsocks_2009013101.orig.tar.gz - well, and this is the archive with source codes we created at the very beginning
Someone might think that everything, this work is complete. If you are really lucky, then yes. In practice, this is where the simple and general part ends, and individual disassembly begins with each person with their own package. Well, you squandered your terminal back to the package building process. Who has already run away at all - you can open the newly-collected darkk-redsocks_2009013101-1_amd64.build file (you will, of course, have your own architecture instead of amd64), and see what the lintian stern censor says:
Now running lintian ...
W: darkk-redsocks: binary-without-manpage usr / bin / redsocks
N:
N: Each binary in / usr / bin, / usr / sbin, / bin, / sbin or / usr / games should
N: have a manual page
N:
Note:
N: these programs should have
N: its own manual page
N: sufficient) because other manual page viewers such as xman or tkman
N: don't support this.
N:
If you want a man page, it can be
N: able to find it anyway; however, it is still best practice to make the
N: case of the man page.
N:
N:
May not be able to determine what man pages are
N: available. In this case, after confirming that all binaries do have man
Please add
N: a lintian override.
N:
N: Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:
N: Severity: normal; Certainty: possible
N:
Finished running lintian.
And he tells us that there is no manual page for the binary. As it is known, decent people should provide every binary with at least a simple mana describing what it is. And we have something in the package and it is not. there are always two ways out: the first is to ask the author of the program to write a manus The second is to write a mana and either ask the author to add it to the program, or put it in the package himself, pointing himself in copyrights.
But on the whole, then only changes are left to us from the work on the package, and if you want to correct something, a thoughtful reading of the Debian Policy .
What other pitfalls await us?
The largest and most frequent stone is license purity. My friends, you just can not imagine how many people have run into it. You take the program, compile it into a package, and debian-legal says to you: “guy, and you generally know that the src / face / ob / table.cpp file is taken from another program, and you did not specify it in copyrights ? And the entire contents of the src / super / karambol / directory is generally distributed under a non-free license. Ah ah ah". But suppose you corrected an error, somehow miraculously persuaded the author of the program to write a free analog instead of a non-free code, and your package was included in the repository. But after a week, a meticulous user discovers: “dude, how can that be. They have here in the messenger client icons are displayed. And each logo is always distributed under the license of its program. So you do not have the right to archive the icon of a non-free ICQ 6.5 client. ” Of course, with these words, debian-legal frowns and with an accurate kick kicks your already received package out of the repository. That is why, by the way (I promised to tell you), qutIM's package was condescendingly taken into ubuntu, and I'm not even trying to get into Debian with him until all licensing issues are resolved. For the only non-free icons I will drive slippers through the entire community.
Another extremely important issue is, oddly enough, the authors of the programs. Pray for the author whom you will easily convince to accept corrections, additions or something else upstream. Because such authors are very rare. Take, for example, Pidgin's src-package, admire. It contains a large bundle of patches from the debian community. Upstream pidgin does not take them. And if you try to bring something good into Gnome ... they say, even Thorvalds did it with difficulty.
Sometimes you may be shown some kind of incorrect placement of directories or the absence or incorrect size / format of some icon for a shortcut to a program in sneakers - lintian likes to swear at it, and you should listen to it first. But these are all fairly easily fixable bugs, but the first two problems are really serious and durable.
At this point, I say goodbye to you for a few days, next time I will tell you how to create your own repository and, if I have time, how to check your kosher packages using pbuilder.
Source: https://habr.com/ru/post/50716/
All Articles