どのDebianパッケージがビルドするときにサービスに依存しますか?

どのDebianパッケージがビルドするときにサービスに依存しますか?

複数の異なるパッケージに依存するパッケージの構築に問題があります。その一部にはサービスが含まれています。問題のサービスは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パッケージ、ライブラリパッケージ、サービスを含むパッケージなど)。

おすすめ記事