複数の異なるパッケージに依存するパッケージの構築に問題があります。その一部にはサービスが含まれています。問題のサービスはpostinstスクリプトから起動しようとします。これにより、systemdサービスがビルド環境にインストールされず、ビルドが失敗します。
同様の問題があるいくつかの公式パッケージを見たいです。この時点では依存関係サービスを実行する必要はありませんが、postinstスクリプトはまだ機能するはずです（もちろん？！）。この場合、名前がパッケージ名と異なるため、サービスを手動で開始しようとします（さらに、実際にはパッケージ2サービスに何かがありますが、私は外れました）。
私のスクリプトは現在次のことを試みています。
systemctl enable ipload
systemctl start ipload
Ubuntuシステムにパッケージをインストールすると正常に動作しますが、-devそのパッケージに依存するシステムを構築すると失敗します。
私の質問は次のとおりです
同様の問題がある既存の公式Debianパッケージはありますか？通常、サービスを起動し、ビルドに必要な他のパッケージに依存していますか？
これにより、同様の方法で独自のパッケージを作成できます。
答え1
dh_installsystemdサービスを設定するには、パッケージビルドでそれを使用する必要があります。これにより、管理者スクリプトで適切に信頼できるコードスニペットが生成されます。例を見るg810-led~のdebian/rules;パッケージ名と一致しないユニットを処理する方法を示します。
dh_installsystemd --no-stop-on-upgrade --no-start --name=g810-led-reboot
--no-stop-on-upgrade（またはを使用しないでください--no-start。）
結果には以下postinstが含まれます。
# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask 'g810-led-reboot.service' >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'g810-led-reboot.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'g810-led-reboot.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'g810-led-reboot.service' >/dev/null || true
fi
fi
# End automatically added section
これはdeb-systemd-helper、存在するかどうかにかかわらず、インストールを処理するために使用されますsystemd。
また、そのprerm合計も表示できますpostrm。
-devしかし、パッケージが最終的にパッケージ配送サービスに依存することは一般的ではありません（前例ではありません）。コンテンツをさらに分割することもできます（-devパッケージ、ライブラリパッケージ、サービスを含むパッケージなど）。
答え2
私は得るのが難しいdh_installsystemd仕事をするために完璧にするためにとられたさまざまなステップに自分自身の答えをしたいと思います（ほぼ1）。
長くする
ディテールをオンにしない限り、作業中の機能の兆候は非常に軽くなります。これはファイルに以下を追加することによって
debian/rules行われます。export DH_VERBOSE=1デバッグが完了したら削除またはコメントアウトします。
ファイルを次の場所に配置します。
debian/...私の元の投稿では、ファイルは次のように定義されています
contrib/ipload.service。ファイルをインストールしています。手で（対応するファイルを使用iplock.install）次に、systemctlコマンドを使用してサービス²を設定します。systemd が提供する debhelpers で使用するには、
debian/...次のようにファイルを移動する必要があります。git mv contrib/ipload.service debian/iplock.ipload.service名前がどのように変わるかを確認してください。今、3つの部分に分けられます。
iplock--サービスを追加するパッケージの名前ipload- サービスファイル名（以前と同じ）service--systemd ファイルの種類、サービス
互換性レベルが正しいことを確認してください。
互換性レベルを定義する方法は2つあります。古い方法はファイルを持つことです
debian/compat。ファイルには1つのレベルのみが含まれます（たとえば、12などの10進数を含むテストファイル）。debhelper-compat新しい方法はファイルに依存関係を作成することですdebian/control。Build-Depends: debhelper-compat (= 12), ...どちらも少なくとも12個あることを確認してください。それ以外の場合は、システム化された debhelpers を上書きします。確かに完全に始めてください（無視されます）。ずっと前にパッケージを作成した場合は、より低い互換性レベルを使用することは不可能ではありません。
サービスファイルの実際のインストール
多くのプロジェクトとは異なり、このプロジェクトには2つの
.serviceファイルがあります。 1つが呼び出され、パッケージipwall.serviceに入ります。ipwall上記のように、他のものは名前を付けてパッケージipload.serviceに入れる必要がありますが、2番目のものは名前の不一致によって失敗します。iplock上記のように、最初にファイル名を正しく変更する必要がありました(
<package name>.<service name>.<extension>)。次に、次のようにオーバーライドする必要があります。override_dh_installsystemd: dh_installsystemd dh_installsystemd --name=ipload最初の呼び出しは正しく
dh_installsystemdインストールされますipwall（実際には通常どおりすべてデフォルトです）。 2番目の呼び出しは名前（ipload）を指定し、それがインストールされていることです...尋ねることもできます。 ！これは上記のファイル名で定義されているためにインストールiplock.ipload.serviceされますiplock。
1私が言ったほぼこれは、ユーザーが作成され、サービスが開始され、次の設定が更新されるため、まだ問題があるためです。したがって、最初の実行時にデフォルト設定が使用され、管理者の変更は不要です。一度に一つの質問だと思います。
²これは、ビルドシステムにsystemdがインストールされていないために以前に遭遇した問題です。スクリプトはシステムツールを使用する前に実際にディレクトリをテストします/run/systemd/system。
if [ -d /run/systemd/system ]
then
...here you can use systemctl...
fi