メンテナーになります。 パート3

そして、3日目がありました。そして、ユーザーが口をそろえたように思いました。美しくて正確で、そのコーシャの誇りがそのように破裂するように私のお気に入りのパッケージをどのように梱包したらよいでしょうか。 それが今日私たちがやることです。

（パート1、2および4 ）



darkkのイニシアチブで、 redsocksパッケージを収集します。これは、翻訳では「Red darkk's socks」を意味します。

最初に、リンクをたどって、ソースとともにアーカイブをダウンロードします。 あなたとの関係はわかりませんが、「darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz」と呼ばれます。 ご存知のとおり、その名前のアーカイブは良くありません。 したがって、最初に解凍して消去します。

$ tar xvf darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz

$ rm darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64.tar.gz

これで、「darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64」というディレクトリができました。 それもダメです 幸いなことに、たとえばプログラムに通常のバージョンがまったくないような極端な場合、Debianでは番号を変更できます。 これは私たちが今やることです：

$ mv darkk-redsocks-77a490422b701875a9fda2bd7d58e62cb7481f64 darkk-redsocks-2009013101

$ tar czf darkk-redsocks_2009013101.orig.tar.gz darkk-redsocks-2009013101

ディレクトリの名前を変更する最初のアクション：バージョンは、日付に現在の日付のバージョン番号を加えた番号になります。今回はバージョンが01になります。2番目は「コーシャ」ソースアーカイブを作成します。 ちなみに、ルールカタログには「name-version」という名前を付け、アーカイブには「name_version.orig.tar.gz」という名前を付ける必要があります。 前者の場合、バージョンの前にハイフンが必要で、後者の場合はアンダースコアです。

奇妙なことに、あなたが私と同じようにプログラムに精通している場合（つまり、人生で初めて見た場合）、プログラムの依存関係に示されているlibevent-devパッケージをインストールします。

$ sudo apt-get install libevent-dev

$ cd darkk-redsocks-2009013101

$ make





個人的に、この手順はエラーで落ちました：

cc -std = gnu99 -Wall -g -O0 -c base.c -o base.o

/usr/include/linux/netfilter_ipv4.h:8からインクルードされるファイルでは、

base.cから：29：

/usr/include/linux/netfilter.h:44：エラー：フィールド 'in'の型が不完全です

/usr/include/linux/netfilter.h:45：エラー：フィールド 'in6'の型は不完全です

make：*** [base.o]エラー1

ここで、付属パッケージの最初の戒めの1つが発効します。アップストリームの作成者と非常に密接に連絡するか、インターネット検索の主要な専門家になります。 今回、私は誇りから、2番目のオプションを選択し、徹底的な検索により、バグが古いことを発見しました。 それは6ヶ月以来現れており、何らかの理由で彼らはそれを修正するために急いではありません。 しかし、あなたはパッケージでローカル修正を行うことができ、今すぐそれを行います（小さな注意：これも別のパッチとして発行しませんが、文化人がアップストリームの作者に送ってパッチを蹴る必要があるため、コードで直接修正しますアップストリームには含まれません。含まれない場合は、そのようなプログラムの作成者に必要です。その間、base.cファイルの行の前に

# include <linux/netfilter_ipv4.h>

挿入する

# include <netinet/in.h>

もう一度入れます。 再びエラー：

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：関数 `terminate '内：

/home/user/build/darkk-redsocks-2009013101/main.c:44：「event_loopbreak」への未定義の参照

私たちは再び検索に乗りますが、何も見つかりません（少なくともI）が、リポジトリにあるevent_loopbreakメソッドがまだ方法を知らないことを巨大なテレパシーの努力によって理解しています。 さて、私たちは言う、私たちは何をすべきか？ debianの新しいバージョンは実験的なリポジトリにのみあります。 個人的には、あえて接続しませんでした。 したがって、次のアクションを実行します。

$ 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*.deb

説明します。 海が非常に不安定なソフトウェアであるリポジトリに接続したくないので、既存のlibeventを削除し、dgetコマンドを使用してダウンロードした新しいバージョンのソースパッケージを収集します。 組み立てられたパッケージが正常にインストールされたので、赤い靴下を再び組み立てようとします。

$ cd darkk-redsocks-2009013101/

$ make

今回はすべてがうまくいきました。 いいね 次に、カタログを確認し、ユーザーが自分のコンピューターにインストールする最終バイナリパッケージで収集する必要があるファイルを理解します。 個人的に、私はこのセットを強調しました：

doc / *-ドキュメント

READMEは同じです

redsocks.conf.example-サンプルファイル

redsocks-実行可能ファイル自体

さて、いくつかのオプションを試してみましょう。

既製のバイナリからgovnopaketを収集しましょう

はい、言い換えれば、それを呼ぶのは難しいので、私はそれをそれと呼ばなければなりません。

注意、このアセンブリオプションは情報提供のみを目的としており、それを使用するユーザーはオズの国の法律に従って7回実行する必要があります。

したがって、アセンブルされたプログラムを使用してディレクトリ内に別のディレクトリ「darkk-redsocks-2009013101」を作成します。 ファイルをコピーして、次の階層が取得されるようにします。

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.example

darkk-redsocks-2009013101 / DEBIANディレクトリを作成し、その中に次の内容の制御ファイルを配置します。

パッケージ：darkk-redsocks

バージョン：2009013101

アーキテクチャ：amd64

メンテナー：Ivan Ivanov <ivan@ivanov.iv>

説明：プロキシへのTCP接続の透過リダイレクタ

TCP接続をある程度リダイレクトするメガパッケージ

いまいましいプロキシ。

制御ファイルを引き続き使用する必要があるため、すぐに少し説明します。 このファイルには、パッケージのすべての説明が格納されます-アーキテクチャが構築されている対象、パッケージに付随している人など。原則として、すべてが明確であり、説明項目のみが対象です。 それはcな方法で配置されています。最初の行では、「Description：」という語の直後に短い説明が書かれています。 「 Packagename is a description 」行で置換できるように、ルールに従って記録します。 つまり、サブジェクトと "is"（可能性のある記事）のない小さな文字で書かれており、末尾に句読点が含まれていません。 この場合、パッケージの名前は短い説明に記載しないでください。また、1つの文に収まり、60文字を超えないようにする必要があります。 次の行から始まるのは、パッケージの完全な説明です。 説明の各行は、再び80文字（これは、すべての種類のスクリプトを含む一般的な要件です）以内で、スペースで始まる必要があります。 説明に空の行を挿入する場合は、その行にスペースとピリオド文字を入れます。 さて、良いDebianの伝統によれば、ファイルは空行で終わるべきです。

さて、制御ファイルが完成しました。 保存した後、チームでパッケージを収集します

$ dpkg -b darkk-redsocks-2009013101

この場合、darkk-redsocks-2009013101はパッケージのファイルをプッシュしたディレクトリの名前であり、組み合わせて、受信したdebパッケージの名前にもなります。 光景を楽しんだ？ 緊急入力中

$ rm -rf darkk-redsocks-2009013101 darkk-redsocks-2009013101.deb

このビルド方法に完全にうんざりするまで。 そして、次の方法に進みます。

文化人のようなパッケージをまとめる

そして今、私たちは再びバイナリを収集しただけの状況にあります。 この状況を修正しましょう。 入力する：

$ make distclean

アセンブリ中に生成されたすべてのバイナリファイルとオブジェクトファイルの両方からカタログを削除しました。 次に入力します

$ dh_make

単一のバイナリ、つまり単一のバイナリを生成するパッケージを作成したいという情熱的な要望をお知らせします。 dh_makeユーティリティは、パッケージメンテナの負担を大幅に軽減するdebhelperユーティリティのセットを指します。 彼女は、パッケージのビルドに使用するファイルを含むdebianディレクトリを生成しました。 このディレクトリに移動して、次のファイルを除くすべてを削除します。

変更ログ

コンパット

制御

著作権

docs

ルール

良い方法では、監視ファイルは私たちを傷つけることはありませんが、フォローできる通常のアップロードされたリリースはなく、gitリポジトリのみであるため、必要ありません。 次に、制御ファイルを開き、そこからすべてを削除して、新しい美しいコンテンツを作成します。

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.



ここでは、原則として、いくつかの点を除いてすべてが明確です。 最初にソースパッケージの説明があり、次に空の文字列、バイナリパッケージがあります。 「アーキテクチャ：any」とは、この場合、コンパイル済みのバイナリパッケージに任意のアーキテクチャを置き換えることができることを意味します。 たとえば、すべてのアーキテクチャで同じdevパッケージをビルドする場合、そこに「all」と記述します。 1つのsrcパッケージで複数のバイナリパッケージを収集する必要がある場合があります。たとえば、何度も言及したqutIMがアセンブルされます。そのソースコードは、qutimパッケージに組み込まれているプログラム自体だけでなく、潜在的なプラグインのヘッダーファイルも提供します-それらを配置する必要がありますqutim-devパッケージに。 このような場合、複数のバイナリパッケージの制御ファイルの説明を書き込み、それらを空白行で区切ります。 次に、Build-Dependsセクション。 まず、コンパイラー、メーカーなどを指定する必要はありません。 まだ奇跡がない場合は、ビルド必須パッケージをインストールし、既にインストールされている場合は、指定しないパッケージのリストが含まれるファイル/ usr / share / doc / build-essential / listを開きます。ビルドの依存関係。 次はdebhelperパッケージです。 これは、構築する多くの喜びを提供するパッケージであり、どのバージョンを使用できるかは、そのバージョンによって異なります。 私たちがアセンブリ用のスクリプトを書くとき、あなたは個人的にそのパンを楽しむことができるので、私は7番目のバージョンを残すことをお勧めします。 さて、libevent-devは、かつて苦しんでいたパッケージです。 必須-バージョンを示します。

さらに進んでいます。 compatファイルを開いて、そこで番号を確認します-制御ファイルのdebhelperバージョンと同じである必要があります。つまり7です。なぜ必要なのか-正直に言うと、自分自身を知りませんが、怠を見つけます。 しかし必要:)

変更ログファイルを開き、次の形式にします。

darkk-redsocks (2009013101-1) experimental; urgency=low



* Initial release (Closes: #123456)



-- Vsevolod Velichko <torkvemada@nigma.ru> Sat, 31 Jan 2009 04:07:47 +0300

必要なバージョンのlibevent-devパッケージしか取得できないため（実際にはそこからダウンロードしたため）、リリースを実験版に変更しました（ubuntuの場合は、そこにジャンティのようなものをインストールする必要があると思います）。 「Closes：＃123456」というフレーズは、パッケージをリポジトリに追加するときにdebianまたはubuntuのバグ追跡システムが対応する番号のバグを自動的に閉じるために必要です。 最初のパッケージングの場合、私たちと同様に、これはパッケージの作成を計画するための「バグ」の番号です。ITP（パッケージへの意図）。 このようなバグはなかったので、公式リポジトリにパッケージを含めるときまで、そこに任意の番号を付けます。 将来、「dch -i」コマンドを実行して、前の記事で述べた「dch」ユーティリティを使用して変更ログを更新します。

次に、著作権ファイルに移動します。 すでに標準のテンプレートが入力されています。詳細を入力するだけです。 このフォームに持ってきます：

このパッケージは、Vsevolod Velichko <torkvemada@nigma.ru>によってdebianizedされました。

2009年1月31日（土）04:07:47 +0300。



http://darkk.net.ru/redsocks/からダウンロードされました



上流の著者：



レオニード・エヴドキモフ<leon@darkk.net.ru>



著作権：



Copyright©2009 Leonid Evdokimov



ライセンス：



このプログラムはフリーソフトウェアです。再配布および/または変更できます

によって公開されたGNU General Public Licenseの条件の下で

フリーソフトウェア財団、ライセンスのバージョン3、または

（オプションで）それ以降のバージョン。



このプログラムは、役に立つことを期待して配布されています。

しかし、いかなる保証もありません。 暗黙の保証なしでも

特定の目的に対する商品性または適合性。 をご覧ください

詳細については、GNU General Public License。



GNU General Public Licenseのコピーを受け取っているはずです

このプログラムと一緒に。 そうでない場合は、< http://www.gnu.org/licenses/ >を参照してください 。



Debianパッケージの著作権は2009年、Vsevolod Velichko <torkvemada@nigma.ru>および

GPLの下でライセンスされています。「/ usr / share / common-licenses / GPL」を参照してください。

しかし、その後、パッケージの作成時にmagic debhelperパッケージが処理するファイルの編集を開始します。 最初のものはdocsファイルです。 ドキュメントディレクトリにインストールする必要があるファイルのリストを保存します。 一般的なケースでは、srcパッケージがアセンブリ中に1つのバイナリパッケージのみを作成する場合、このファイルはdocsという名前で残すことができます。 しかし、将来混乱しないように、すぐにバイナリパッケージの名前で名前を変更します。

$ mv docs darkk-redsocks.docs

それを開いて、そこにすべてのドキュメントを追加します：

Readme

doc / *

プログラムの次の項目はサンプルファイルです。 彼のために、darkk-redsocks.examplesファイルを作成して書き込みます：

redsocks.conf.example

Makefileはパッケージのインストール方法を知らないため、darkk-redsocks.installファイルも作成します。 次のエントリを書き込みます。

redsocks usr / bin /

usrの前にスラッシュは置かれないことに注意してください。

説明されているファイル？ 素晴らしい、最後のファイルを編集するだけです。 エディターでルールファイルを開き、容赦なくルート化を開始します。 構成セクションは必要ありません。これを行う方法はわかりません。このセクションとすべての参照を削除します。 残りのファイルは、このようなエレガントな外観に縮小されます。

＃！/ usr / bin / make -f

＃-*-メイクファイル-*-



＃詳細モードを有効にするには、コメントを外します。

#export DH_VERBOSE = 1



ビルド：ビルドスタンプ

ビルドスタンプ：

dh build

$ @をタッチ



きれいな：

dh clean



インストール：ビルド

dhインストール

$ @をタッチ



binary-indep：インストール

dh binary-indep



binary-arch：インストール

dh binary-arch



バイナリ：binary-indep binary-arch

.PHONY：クリーンなbinary-indep binary-archバイナリインストールをビルドします

注：ソースファイルでは、すべての呼び出しは「dh_something」のように見えました（例：「dh_install」）。 これらはデブヘルパーの原子的反応であり、対応するマンで読むことができます。 呼び出しがdhユーティリティに行くときに「dh install」などのコマンドを使用します（対応するマニュアルページも参照してください）。 このユーティリティは、渡されたパラメーターが指す特定のグループから各スクリプトを順番に呼び出します。 したがって、かなり単純なパッケージがありますが、これらの呼び出しのほとんどはアセンブリ中にアイドル状態になりますが、たとえば、パッケージにマナページを追加する場合、darkk-redsocks.manpagesファイルを作成し、そこでこのページを指定するだけで十分です。次のビルドでは、dh自体が必要に応じてそれを配置し、mandbにこのページを登録するスクリプトでさえ追加します。

これで、ファイルの編集は完了です。 debianディレクトリから親ディレクトリに移動し、次のように入力します。

$ debuild --lintian-opts -i

パスワードの要求に応じて、結果のsrc-packageに署名し、慎重に調べます。 上のディレクトリには一連のファイルがあります。

darkk - redsocks_2009013101-1_amd64.build- これは、パッケージアセンブリの進行状況全体が記録されるログです

darkk-redsocks_2009013101-1_amd64.changes はsrc-packageの補助ファイルです

darkk-redsocks_2009013101-1_amd64.deb- 実際にアーキテクチャ用に組み立てられたパッケージ

darkk-redsocks_2009013101-1.diff.gz- 元のソースと比較して、すべての変更を保存するパッケージ化された差分ファイル。 原則として、これはすべてdebianディレクトリの内容であり、この場合、修正されたbase.cファイルを覚えていますか？

darkk-redsocks_2009013101-1.dsc はsrcパッケージのメイン記述ファイルです

darkk-redsocks_2009013101.orig.tar.gz- まあ、これは最初に作成したソースコードを含むアーカイブです

誰かがすべて、この作業が完了したと考えるかもしれません。 本当にラッキーなら、はい。 実際には、これは単純で一般的な部分が終了し、個々の分解がそれぞれ独自のパッケージで始まる場所です。 さて、ターミナルをパッケージアセンブリプロセスに浪費しました。 彼がすでに完全に脱出した人-新しく組み立てられたdarkk-redsocks_2009013101-1_amd64.buildファイル（もちろん、amd64の代わりに独自のアーキテクチャを持っています）を開き、リンチの厳しい検閲が示すことを確認できます。

現在、lintianを実行しています...

W：darkk-redsocks：バイナリなしのマンページusr / bin / redsocks

N：

N：/ usr / bin、/ usr / sbin、/ bin、/ sbin、または/ usr / gamesの各バイナリ

N：マニュアルページがある

N：

N：manプログラムにはいくつかの機能をチェックする機能がありますが、

N：NAMESセクションのプログラム名、これらのプログラムにはそれぞれ

N：独自のマニュアルページ（適切なマニュアルページへのシンボリックリンクは

N：十分）xmanやtkmanなどの他の手動ページビューアー

N：これをサポートしません。

N：

N：manページの名前がケースごとにバイナリと異なる場合、manは

N：とにかくそれを見つけることができます; ただし、作成することは依然としてベストプラクティスです。

N：マニュアルページの大文字と小文字がバイナリの大文字と小文字に一致します。

N：

N：マニュアルページが、このパッケージのある別のパッケージによって提供されている場合

N：依存します、lintianはmanページが

N：利用可能。 この場合、すべてのバイナリにmanがあることを確認した後、

N：このパッケージとその依存関係がインストールされた後のページ、追加してください

N：リンチアンオーバーライド。

N：

N：詳細については、Debianポリシーマニュアルセクション12.1（マニュアルページ）を参照してください。

N：

N：重大度：通常。 確実性：可能

N：

リンチアンの実行を終了しました。

そして彼は、バイナリ用のマニュアルページはないと言っています。 ご存知のように、まともな人々はすべてのバイナリに、少なくともそれが何であるかを説明するシンプルなマナを提供すべきです。 また、パッケージには含まれていません。 常に2つの方法があります。1つ目は、プログラムの作成者に男を書くように頼むことです。 2つ目は、男を書いて、作者にプログラムに追加するように頼むか、自分でパッケージに入れて、著作権で自分自身を示すことです。

しかし、一般的に、パッケージの作業から私たちに残された編集、および何かを修正したい場合、 Debian Policyの思慮深い読書だけです。

他にどんな落とし穴が待っていますか？

最大かつ最も頻繁な石は認可された清潔さです。 友よ、あなたはこれに何人の人が出くわしたか想像できません。 プログラムを取り出してパッケージに入れると、debian-legalから次のように伝えられます。「男、src / face / ob / table.cppファイルが別のプログラムから取られたのを知っていますが、著作権で指定していませんか？ ？ また、src / super / karambol /ディレクトリのすべてのコンテンツは、一般にフリーではないライセンスの下で配布されます。 ああああ。」 しかし、エラーを修正し、なんらかの方法でプログラムの作者に非フリーコードではなく無料のアナログを書くように説得し、パッケージをリポジトリに含めたとします。 しかし、1週間後、細心の注意を払ったユーザーが次のことを発見しました。 ここで、メッセンジャーでは、クライアントアイコンがここに表示されます。 そして、各ロゴは常にそのプログラムのライセンスの下で配布されます。 したがって、ICQ 6.5独自のクライアントアイコンをアーカイブにアーカイブする権利はありません。 もちろん、これらの言葉で、debian-legalは眉をひそめ、よく狙ったキックでリポジトリから既に受け入れられたパッケージnafigを投げます。 そのため、ところで（私が伝えると約束しました）、qutIMパッケージはubuntuに受け入れられ、すべてのライセンス問題が解決するまでDebianで対処しようとさえしません。 プロプライエタリなアイコンだけでも、コミュニティ全体をスリッパで駆り立ててくれます。

別の非常に重要な問題は、奇妙なことに、プログラムの作者です。 アップストリームで修正、追加、または何か他のものを受け入れるように簡単に説得する著者のために祈ってください。 そのような著者は希少だからです。 たとえば、Pidgin srcパッケージをご覧ください。 debianコミュニティからのパッチの大規模なバンドルが含まれています。 上流では、ピジンはそれらを摂取しません。 そして、あなたがGnomeに何か良いものを持ち込もうとするなら、彼らはTorvaldsでさえそれを困難にしたと言う。

それでも、時々、間違ったディレクトリの配置や、スニーカーのプログラムへのショートカットのアイコンの不在または間違ったサイズ/形式が表示される場合があります-リンティアンはこれを誓うのが大好きで、まずそれを聞く必要があります。 しかし、これらはすべてかなり修正しやすいバグですが、最初の2つの問題は本当に深刻で永続的です。



この時点で数日お別れをします。次回は、自分のリポジトリを作成する方法と、時間があれば、pbuilderを使用してパッケージのコーシャーをチェックする方法を説明します。