カスタム、バックポート、パッチパッケージを含むDebian Jessieリポジトリのフォークをホストしています。各製品リリースはこのリポジトリにISOインストーラを生成します。今、数ヶ月前のバージョンから今月のバージョンへのアップグレードが失敗していることを確認しました。この問題は、/etc/sysctl.d/ 以下のカスタムパッケージ構成ファイルが正しくないために発生します。これにより、アップグレード中にsystemd（procpsによる）構成が失敗します。カスタムパッケージが変更されましたが、アップグレード中にこのパッケージの構成はシステム構成後に発生します。
1つの可能性は、systemdをパッチし、カスタムパッケージを依存関係として追加することです。
もう1つのアイデアは、debian / controlファイルで置換/衝突を使用することです。しかし、アップグレード順序に関するドキュメントが見つからないようです。 apt-get アップグレードはパッケージを交換することから始まり、他のパッケージをアップグレードし続けますか？
systemdの前にカスタムパッケージを設定する方法についての他のアイデアはありますか？ （フルアップグレードを開始する前に手動で手動でインストールする必要はありません）
答え1
フルアップグレードを開始する前に手動でインストールする必要はありません。
アパートにはそのような施設がないので難しいです。
通常、アップグレードを実行するときにdpkgが呼び出され、ダウンロードしたすべてのパッケージをインストールし、意味のあるグループに分割し、すべて解凍して設定します（これは非常に簡単で、実際にはそれ以上のことを行います）。そして、パッケージ構成が失敗するたびに、何も構成されないまで別のパッケージ構成を試みます。したがって、デュアルアップグレードを実行できます。 1つ目はdpkgが終了することを期待し、2つ目はプロセスを完了します。
しかし、私はこれを信じておらず、推奨されるアプローチは、関連パッケージを独立してアップグレードして（を使用してinstall package）アップグレードを実行することです。upgrade package-通常、インストール前にアンインストールが優先されるため、パッケージのアンインストールを最初に使用することもできます。
1つの可能性は、systemdをパッチし、カスタムパッケージを依存関係として追加することです。
これは別のオプションです。 systemdに接続すると、Depends: package >= versiondpkgは最初にこのパッケージをインストールします。他にはおすすめしないようです。
答え2
したがって、構成ファイルのエラーが原因でsystemdがアップグレードされたときにエラーが発生する古いカスタムパッケージがあります。
与えられた管理者スクリプトの実行順序、パッケージの新しいバージョンが介入できる最も早い時間は、新しいpreinst upgradeパッケージが解凍される前、つまりpostinst configureそのステップの前に発生するステップです。新しいファイルでpreinst upgrade問題のあるファイルを修正するか、別の場所に移動してpostinst configureスクリプトを使用して残っている問題を修正できます。
これは、APTが同じ実行でパッケージとシステムをアップグレードすることを決定した場合にのみ機能します。他に何をすべきかによって、APTはsystemdを完全にアップグレードしてからパッケージを完全にアップグレードすることを決めることができると思います。パッケージの新しいバージョンに対してシステムの依存関係を宣言すると、これを回避できます。Depends:これにより、postinst configureパッケージが最初に実行されます。Breaks:systemdと以前のバージョンのパッケージの関係実際に問題Breaks:のすべてが公式のDebianパッケージであればそうなると思います。問題は、新しいsystemdパッケージ（または古いパッケージですが遅すぎました）を修正する必要があることです。