もう一度debパッケージについて

Debパッケージは、特に使用方法がわかっている場合に非常に便利なツールです。 この件に関する私自身の経験を共有しようと思います。

準備する

debパッケージの作成を開始するには、いくつかのパッケージをインストールする必要があります。

$ sudo apt-get install dh_make 

ソースフォルダーの準備

dh_makeおよびその他のユーティリティがソースフォルダーで機能するためには、特定の形式にする必要があります。

フォルダーの名前はパッケージ名にする必要があります。 つまり プログラムバージョン0.1のPluginsフォルダーがある場合、 plugins-0.1というフォルダーを作成します。

 $ ls VKSPlugins $ mv VKSPlugins/ libvksplugins-0.1 $ ls libvksplugins-0.1 

次に、このフォルダーでアーカイブを作成する必要があります。 アーカイブには、名前に* .orig.tar.gzが含まれている必要があります。

 $ tar -zcf libvksplugins_0.1.orig.tar.gz libvksplugins-0.1 $ ls libvksplugins-0.1 libvksplugins_0.1.orig.tar.gz 

最後の準備手順は、ソースフォルダーに多くのユーティリティファイルを含むdebianフォルダーを作成することです。 これを行うには、次のコマンドを実行する必要があります。

 $ cd libvksplugins-0.1/ $ dh_make Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch? [s/i/m/l/k/n] l Maintainer name : User Name Email-Address : user@name.ru Date : Wed, 19 Aug 2015 14:55:53 +0300 Package Name : libvksplugins Version : 0.1 License : blank Type of Package : Single Hit <enter> to confirm: Skipping creating ../libvksplugins_0.1.orig.tar.gz because it already exists Done. Please edit the files in the debian/ subdirectory now. plugins uses a configure script, so you probably don't have to edit the Makefiles. 

このコマンドを実行するプロセスでは、作成するアーカイブの種類について質問されます。最も単純なものは単一です。

パッケージのセットアップ

すべてのパッケージ設定は、 debianディレクトリ内のファイルを編集することにより行われます。 使用するファイルを検討してください。

• changelog-パッケージ履歴。
• コントロール-メインパッケージの構成。
• ルール-パッケージのMakefileに類似。

これらのファイルに加えて、多くの* .exファイルがdebianフォルダーに作成されますが、これはさまざまな設定の例ですが、それらは使用しないため、削除する必要があります。

変更ログ

このファイルには、パッケージの変更履歴と現在のパッケージバージョンが含まれています。 その内容を見てみましょう：

 $ cat changelog libvksplugins (0.1-1) unstable; urgency=low * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> -- User Name <user@name.ru> Wed, 19 Aug 2015 15:03:51 +0300 

最初はパッケージの名前-libvksplugins 、次にそのバージョンです。 バージョンは、記号「-」で2つの部分に分かれています。 最初の部分はパッケージ内のプログラムのバージョンを示し、2番目の部分はパッケージの「リビジョン」を示します。 リビジョンはパッケージバージョンです。 そのようなパッケージが以前になかった場合、リビジョンは1です。このバージョンのプログラムを含むパッケージがすでに存在していたが、そこに変更があった場合、リビジョンは増加します。

不安定という言葉は、パッケージが安定していないことを示します。 ユーザーマシンでは適切にテストされていません。

urgency = lowという語は、変更の緊急性を示します。 なぜなら 緊急性がない場合、値は低くなります。 深刻な脆弱性またはエラーを修正するパッケージを作成している場合、値をhighに設定できます。

最初の行が空の行の後に、最初のエントリが続きます。

 * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP> 

Debianでは、ソフトウェア製品のエラー追跡システムのエラーを自動的に閉じるためにchangelogが使用されます。 なぜなら この場合、私はそのようなシステムを使用せず、この行は次の形式を取ります。

* Initial release


最後の行は、録音を行った人の署名です。 名前と住所、および変更日が含まれています。

debパッケージをインストールすると、変更ログファイルが次の場所にインストールされます。

/usr/share/doc/<>/changelog.Debian.gz


制御

debian /制御ファイルは、debパッケージを作成するときのメイン設定です。 そのようなファイルの例を次に示します。

 $ cat control Source: libvksplugins Priority: optional Maintainer: User Name <user@name.ru> Build-Depends: debhelper (>= 9), cmake Standards-Version: 3.9.5 Section: libs Homepage: <insert the upstream URL, if relevant> #Vcs-Git: git://anonscm.debian.org/collab-maint/plugins.git #Vcs-Browser: http://anonscm.debian.org/?p=collab-maint/plugins.git;a=summary Package: libvksplugins-dev Section: libdevel Architecture: any Depends: libvkspluginsBROKEN (= ${binary:Version}), ${misc:Depends} Description: <insert up to 60 chars description> <insert long description, indented with spaces> Package: libvkspluginsBROKEN Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: <insert up to 60 chars description> <insert long description, indented with spaces> 

ファイルは空の行を使用してセクションに分割されていることがわかります。 各セクションでは、ソースフォルダーから作成された1つのパッケージについて説明します。 それらを順番に考えてみましょう：

ソースこのセクションでは、ソースパッケージを作成する必要があると述べています。 指定されたパラメーターはlibvksplugins です 。つまり、ソースパッケージはlibvkspluginsと呼ばれます 。

優先度このセクションでは、パケットの優先度を設定します。 なぜなら システムは新しいパッケージがなくてもうまくいくので、セクション値はoptionalに設定されます 。 つまり このパッケージはインストールには必要ありません。 優先順位についてはこちらをご覧ください 。

メンテナーこのセクションでは、パッケージの作成者の連絡先について説明します。 その形式は非常に単純で、追加の説明は不要です。

Build-Dependsパッケージの依存関係をインストールする最も重要なセクションの1つ。 パッケージをアセンブルするには、このセクションで指定された依存関係を満たす必要があります。 つまり アセンブリとインストールの依存関係のリストは異なる場合があります。

依存関係はdebhelper（> = 9）、cmakeであることがわかります。 debhelper依存関係（> = 9）は 、デフォルトですべてのパッケージに設定されています。 dh_ *形式のプログラムを正しく動作させるために必要です。

ソースフォルダーにCMakeLists.txtファイルが含まれていたため、2番目のcmake要素が追加されました。 アセンブリには、 CMakeアセンブリシステムが使用されます。 プログラムの依存関係を調べるには、そのドキュメントを読むことができます。 または、 dpkg-depcheckコマンドを使用できます。 このコマンドは次のように実行する必要があります。

 $ dpkg-depcheck -d ./configure 

しかし、なぜなら CMakeを使用する場合、構成スクリプトはありません。次のように使用します。

 $ mkdir build && cd build $ dpkg-depcheck -d cmake ../ ..... Packages needed: libxml2:amd64 cmake libkrb5support0:amd64 language-pack-ru-base libnettle4:amd64 ..... libedit2:amd64 libtasn1-6:amd64 qt4-qmake libgssapi-krb5-2:amd64 libhcrypto4-heimdal:amd64 ..... libroken18-heimdal:amd64 libsqlite3-0:amd64 libqt4-dev libssl1.0.0:amd64 ..... 

ここで注目すべき点は次のとおりです。

cmake
qt4-qmake
libqt4-dev

残りはデータの依存関係です。 さらに、cmakeはすでにビルドの依存関係のリストに含まれています。 原則として、そのままにするか、使用するバージョンを指定できます。

 $ apt-cache show cmake | grep Version: Version: 2.8.12.2-0ubuntu6 

同時に、使用するcmakeのバージョンがCMakeLists.txtに示されます。

 $ cat CMakeLists.txt | grep cmake_minimum cmake_minimum_required(VERSION 2.8.4) 

開発者の方がよく知っていると思うので、CMakeLists.txtからバージョンを示します。 Qt 4では、バージョン番号ですべてが明確になっていますが、良心を明確にするために、バージョンを確認します。

 $ apt-cache show qt4-qmake | grep Version: Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1.1 Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1 $ apt-cache show libqt4-dev | grep Version: Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1.1 Version: 4:4.8.6+git49-gbc62005+dfsg-1ubuntu1 

つまり Qt 4では、バージョン4.8.6を指定します。

 Build-Depends: debhelper (>= 9), cmake (>= 2.8.4), qt4-qmake (>= 4.8.6), libqt4-dev (>= 4.8.6) 

Standards-Versionファイルが作成された標準のバージョン。 この値を変更する必要はありません。

セクション パッケージのセクション、つまり 単一のタスクを実行するパッケージのグループ。 Debianポリシーセクション2.4は、この問題をより詳細に説明しています。

ホームページプロジェクトホームページ 。 なぜなら このコードを作成しましたが、ページはありません。この行を削除してください。

Vcs- *プロジェクトリポジトリへのリンク。 どちらも持っていないので、これらの行を削除します。

その他のパッケージソースパッケージが記述されているファイルセクションの後に、ソースパッケージから作成された他のパッケージを記述するセクションがあります。 パッケージ作成スキーム：



図から、プログラムのソースから、4つのパッケージを取得したいことがわかります。

• ソースパッケージ
• バイナリーを含むパッケージ（ライブラリー自体）;
• 開発パッケージ（ヘッダーファイル）;
• ドキュメント付きのパッケージ。

問題は、なぜそんなに多くのパッケージがあるのですか？ stackoverflow.comの関連する議論を読んだ場合、パーティションの主なアイデアは、ほとんどのユーザーがヘッダーファイルとドキュメントを必要としないということです。そのため、これらのファイルを分離することで、プログラムのネットワーク負荷とインストール速度を減らすことができます。

この質問に対する私の個人的な答えは、そのようなパーティションは、それをどのように使いたいかに応じてプログラムを構造化するのに役立つということです。 開発のために、devパッケージを配置しますが、使用するためではありません。

上記のパッケージに加えて、プログラムのデバッグビルドでdbgパッケージを作成できます。 これは、プログラムがクラッシュし、手元にデバッガがある場合に便利です。 しかし、私はまだこれを行う方法を理解できませんでした。 ドキュメントはこの質問に答えていません。 あなたがそれで説明されているようにすると、空のパッケージを取得するか、アセンブリ中に大量のエラーを取得します。

上の図の図は、ソースパッケージがlibvksplugins_sourceと呼ばれていることを示していますが、制御ファイルはソースパッケージがlibvkspluginsと呼ばれることを示しています。 実際、実際にはlibvkspluginsと呼ばれ、バイナリを含むパッケージはlibvksplugins ... debと呼ばれます 。 この混乱の本質は、ソースパッケージがtarアーカイブとサービスファイルであり、バイナリパッケージがdeb拡張子を持つアーカイブであることです。

ライブラリパッケージの構成ライブラリパッケージの説明を注意深く見てみましょう。

Package: libvksplugins
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Library for creating plugins with VKS 2
This library provides a mechanism for creating plugins
to use in project VKS 2.

Architectureパラメーターは、ビルドされるパッケージのアーキテクチャを設定します。 値anyは、バイナリをアセンブルした後、必要なアーキテクチャがビルドシステムに置き換えられることを意味します。 つまり 64ビットマシンでは、パッケージ..._ amd64 ...を取得し、32ビットマシンでは..._ i386 ...を取得します。

スクリプトまたはテキストを含むパッケージの場合、値をallとして指定する必要があります。

3行目は、作成されるパッケージの依存関係を説明しています。 Debian初心者向け開発者ガイドの第4章で説明されている方法は次のとおりです。

dh_shlibdepsユーティリティは、共有ライブラリのバイナリパッケージの依存関係を計算します。 ELF実行可能ファイルと共有ライブラリのリストを生成し、各バイナリパッケージについて見つけます。 このリストは、 $ {shlibs：Depends}の代わりに使用されます。

dh_perlユーティリティは、Perlの依存関係を計算します。 各バイナリパッケージのperlまたはperlapi依存関係のリストを生成します。 このリストは、 $ {perl：Depends}に置き換えられます。

一部のdebhelperパッケージコマンドは、生成されたパッケージに依存関係を追加する場合があります。 各コマンドは、各バイナリパッケージに必要なパッケージのリストを生成します。 このリストは
$ {misc：Depends} 。

dh_gencontrolユーティリティは、バイナリパッケージごとにDEBIAN /制御ファイルを生成し、 $ {shlibs：Depends} 、 $ {perl：Depends} 、 $ {misc：Depends}などを結果の値に置き換えます。

つまり この行は、パッケージコレクターが依存関係を決定することを示しています。

このセクションの最後のセクションは、パッケージの説明です。 最初の行には簡単な説明が含まれ、後続の行にはより詳細な説明が含まれます。 詳細な説明には、特定の形式が必要です。

• 行はスペースで始まる必要があります。
• 文字列は80文字以下にする必要があります。
• 空行はスペースで始まり、ピリオド文字で構成する必要があります。

ヘッダーファイルパッケージのセットアップヘッダーファイルを含むパッケージはlibvksplugins-devと呼ばれます。その説明は次のとおりです。

Package: libvksplugins-dev
Section: libdevel
Architecture: any
Depends: libvksplugins (= ${binary:Version}), ${misc:Depends}
Description: Development package for libvksplugins
This package provides development files for
library libvksplugins.
.
Also, it contains pkg-config file, to use.

この例では、 Depends行が興味深いです。 このパッケージはlibvkspluginsライブラリのパッケージに依存することを示し、（ = $ {binary：Version} ）は、バイナリパッケージと開発パッケージのバージョンの厳密な一致が必要であることを示します。 ヘッダーファイルはバイナリに厳密に対応する必要があるため、これは重要なポイントです。

ドキュメントパッケージのセットアップライブラリと一緒にドキュメントが提供されるため、個別のパッケージになります。その説明を追加します。

Package: libvksplugins-doc
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Documentation for libvksplugins
Package contains html documentation files for libvksplugins

ここですべてが明確になるはずです。

ルール

このファイルは、パッケージをビルドするためのMakefileに類似しています。 デフォルトでは、次の形式で作成されます。

 $ cat rules #!/usr/bin/make -f # See debhelper(7) (uncomment to enable) # output every command that modifies files on the build system. #DH_VERBOSE = 1 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk # see FEATURE AREAS in dpkg-buildflags(1) #export DEB_BUILD_MAINT_OPTIONS = hardening=+all # see ENVIRONMENT in dpkg-buildflags(1) # package maintainers to append CFLAGS #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic # package maintainers to append LDFLAGS #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed # main packaging script based on dh7 syntax %: dh $@ # debmake generated override targets # This is example for Cmake (See http://bugs.debian.org/641051 ) #override_dh_auto_configure: # dh_auto_configure -- \ # -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) 

これは、Makefile構文のbashスクリプトであることがわかります。 ここで唯一面白いデザインは

 %: dh $@ 

これは、すべての目的でdhコマンドを呼び出して引数を渡すテンプレートです。 パッケージをビルドするには、テキストdh $ @をタブ文字で読むことが重要です。 つまり インデントはスペースではなく、集計です。

なぜなら ソースはCMakeビルドシステムを使用するため、このエントリを次のように変更する必要があります。

 %: dh $@ --buildsystem=cmake 

パッケージ内容

debian / controlでどのパッケージを受け取りたいかを指定した後、どのファイルをどのパッケージに入れるかを指定する必要があります。 これを行うには、 制御ファイルのパッケージ名ごとに、 debianフォルダーに2つのファイルを作成する必要があります。 最初のパッケージはパッケージ 、 Dirs 、2番目のパッケージはInstallと呼ばれます 。 ファイルの本質は、最初にパッケージ用に作成するフォルダーを示し、2番目にパッケージに含めるファイルを示すことです。

それらの内容を見てみましょう：

 $ cat libvksplugins-dev.dirs usr/lib usr/include $ cat libvksplugins-dev.install usr/include/* usr/lib/lib*.a usr/lib/lib*.so usr/lib/pkgconfig/* usr/share/pkgconfig/* 

重要なポイントは、パスに最初の分数がないことと、フォルダーへのパスの最後に分数がないことです。 CMakeがライブラリファイルをインストールする場所を確認した後、次のファイルを作成できます。

 $ for item in $(ls libvksplugins*); do echo "$item:"; cat $item; done libvksplugins-dev.dirs: usr/include/dep572 usr/lib/pkgconfig libvksplugins-dev.install: usr/include/dep572/plugins/* usr/lib/dep572/lib*.so usr/lib/pkgconfig/* libvksplugins.dirs: usr/lib/dep572 libvksplugins-doc.dirs: usr/share/doc/libplugins-0.1 libvksplugins-doc.install: usr/share/doc/libplugins-0.1/*.tgz libvksplugins.install: usr/lib/dep572/lib*.so.* 

セットアップの完了

なぜなら 私のソースでは、追加の説明や著作権の制限はないので、debianディレクトリからすべての余分なファイルを削除します。

パッケージアセンブリ

設定後、パッケージのアセンブリは非常に簡単です。プロジェクトフォルダー（debianサブフォルダーを含む）でコマンドを実行する必要があります。

 $ dpkg-buildpackage -rfakeroot -us -uc 

-us -ucオプションは、作成されたパッケージにgpgキーで署名する必要がないことを示します。 デフォルトのgpg署名キーが設定されている場合、これらは省略できます。 デフォルトの署名キーの指定方法がわかりませんでした。 すべてがうまくいけば、上のフォルダにたくさんのパッケージがあります：

 $ ls -l ../  748 drwxrwxr-x 10 user user 4096 . 20 10:46 libvksplugins-0.1 -rw-rw-r-- 1 user user 2210 . 20 10:47 libvksplugins_0.1-1_amd64.changes -rw-r--r-- 1 user user 6418 . 20 10:47 libvksplugins_0.1-1_amd64.deb -rw-rw-r-- 1 user user 1504 . 20 10:46 libvksplugins_0.1-1.debian.tar.xz -rw-rw-r-- 1 user user 1008 . 20 10:46 libvksplugins_0.1-1.dsc -rw-rw-r-- 1 user user 36713 . 19 14:52 libvksplugins_0.1.orig.tar.gz -rw-r--r-- 1 user user 3262 . 20 10:47 libvksplugins-dev_0.1-1_amd64.deb -rw-r--r-- 1 user user 699564 . 20 10:47 libvksplugins-doc_0.1-1_all.deb 

おわりに

ここまで読んだことがあれば、読むのが大好きです。

このテキストは、職場でdebパッケージを実装した私の経験の結果です。 ネットワークリポジトリ（reprepro）の存在と注意深いバージョントラッキングにより、Astra Linux 1.3、1.4、およびElbrus OSシステムを備えた30台のマシンでさまざまなソフトウェアバージョンを簡単に更新およびテストできることが経験からわかっています。