dpkg --dry-run オプションはインストールを正しくシミュレートしません。

追加の依存関係をインストールせずにパッケージをインストールできることを確認するには、「エミュレーション」モードを使用することをお勧めしますapt。

apt -s install ./mysql-workbench_6.2.3+dfsg-7_armhf.deb

（./どちらが重要かを確認してください）。これにより、dpkg実際のインストールが実行するアクションが出力されます。パッケージのインストールにはが表示されますInst。複数のパッケージがある場合、パッケージを個別にインストールすることはできません。

今重要なのは、依存関係を知らないdpkgからではなく（確かにそうです）、依存関係が十分に強くないので使用できないということです。dpkgパッケージが他のパッケージに依存している場合、依存関係のためにパッケージインストール済み満足できないと満足できなくなります。設定。バラよりDebian Policy Section 7.2:

フィールドDependsが適用されます。ただパッケージ構成について。依存関係が満たされていない場合、パッケージが未構成のままになるのを防ぎ、依存関係が満たされた正しくインストールされたパッケージを、依存関係が満たされていないか、または満たされない他のバージョンに置き換えることができます。 、依存パッケージは未構成のまま（構成しようとするとエラーが発生するため）、正しく機能しません。

自己テストでこれを確認できます。プロセスは次のように失敗します。

dpkg: dependency problems prevent configuration of mysql-workbench

「インストール」ではなく「構成」に注意してください。出力を見ると、パッケージがインストールされているがまだ構成されていないことを意味dpkg -l mysql-workbenchします。iU

で「エミュレーション」モードを有効にすると、既定ではdpkg読み取り専用モードで実行されます。フラグを設定してこれを行いますf_noact。ソースコードでこれを見つけることができます。ソフトウェアパッケージをインストールするときは、何も作成せずにインストールタスクをシミュレートしてから構成手順に入ります。ただなるふりをしてみてこれは、モック操作が実行できる唯一のタスクです。構成には、パッケージでメンテナンススクリプトを実行することが含まれており、そのスクリプトが変更されていないことを確認したり、変更を許可せずに正常な変更を確認できることを確認することは困難です。したがって、あなたの場合、模擬は（模擬ではないテストのように）成功した​​パッケージをインストールし、構成を偽造します。だからエラーが見つかりませんでした...

これは技術的に答えではありませんが、良い質問です。

man dpkgを見ると、テストするオプションについて説明しています。実際の Debian の専門家がもう少し権威のある答えを提供できるといいでしょう。または内容に誤りがある場合は修正してください。

   --no-act, --dry-run, --simulate
          Do everything which is supposed to be done, but don't write any changes. This is used to see what would happen with the specified
          action, without actually modifying anything.

確かではありませんが、本質的にすべてのdpkgがテストするのはコマンドに欠陥があるかどうかだと思います。たとえば、次のような場合：

#dpkg --dry-run -i nonexistent.deb || echo $?
dpkg: error: cannot access archive 'nonexistent.deb': No such file or directory
2

これが結果です。私が気づいた1つの事実は、root権限を必要とする--dry-runを使用してもdpkgがログファイルを使用できないと文句を言うことです。これは--dry-run、私たちが期待どおりに全く行われていないことを意味します。を使用すると、apt-get通常のユーザーのように--simulateを使用できます。

dpkg は非常に低レベルの apt ツールであり、テストの結果からわかるように、実際に .deb ファイルをインストールするまで apt データベースと依存関係ツリーについての知識はありません。したがって、依存関係などではなく、実際のリテラルコマンドデータを推論またはdpkg --dry-runテスト--simulateします。

これは、apt-getでは合理的にうまく実行されますが、完全ではない同じコマンドのように見えますが、実際にはまったく同じではありません。実際に何をしているのかを理解するには、dpkg --simulateのコードを読む必要があります。

この質問を調べてみると、私が思ったことが事実のようです。

https://lists.ubuntu.com/archives/ubuntu-devel/2005-November/013049.html

機能がある場合は.debdpkg -iを試して（または構成が不足しているパッケージで終わる場合）、依存関係dpkg -fを1つずつ手動で確認するのではなく、.debの依存関係を自動的に確認する方法はありますか？

dpkg-buildpackageの "Unmet build dependency: ..."確認のようなものを探していますが、.debsについてです。

次の場所で「gdebi」という新しいアプリケーションを使用できます。 http://people.ubuntu.com/~mvo/gdebi/

debパッケージの依存関係を直接解決できる必要があります。これにはgdebi-gtkとgdebi（およびcliバージョン）が含まれています。これはあなたが望むものかもしれません。そうでない場合は、お知らせください。

これは非常に古いスレッドであり、あなたはGUIツールを探していないと確信しています。しかし、この質問は2005年に存在し、誰かが依存関係を確認できるGUIソリューションを作成したことに注目する価値があります。これは実際にdpkg - - シミュレーション番号私もDebian aptとdpkgの自動化スクリプトをたくさん書いていますが、2つは非常に異なる動作と動作を期待していません。

dpkgを使用して依存関係を決定するためのさまざまなオプション

https://lists.debian.org/debian-user/2006/09/msg00292.html

ここに同じ問題の古いDebianスレッドがあります。 dpkg --dry-run は一般に依存関係を処理しないことがわかります。

https://lists.debian.org/debian-user/2006/09/msg00297.html

dpkg-deb -I package.deb

どんな提案がありますか？これは本質的にと同じであることを示していますapt-cache show package-name。

したがって、少なくとも依存関係を直接確認できます。

 dpkg -I perl_5.26.0-8_i386.deb
 ....
 Pre-Depends: dpkg (>= 1.17.17)
 Depends: perl-base (= 5.26.0-8), perl-modules-5.26 (>= 5.26.0-8), libperl5.26 (= 5.26.0-8)
....

https://lists.debian.org/debian-user/2006/09/msg00312.html

を使用すると、依存dpkg --control pkg_file関係を含むパッケージに関するすべての制御情報が表示されます。

テストしましたが、何も表示されませんでした。最新バージョンではない可能性があります。わかりません。

ご覧のとおり、Debian の開発者はいくつかの提案をしましたが、どれもdpgk --dry-run望むことを行う方法を示していません。

結論として

いくつかのオプションがあります。一つは、依存関係を手動で決定することです。後で独自のdebを作成し、スクリプトのインストールを使用するか、その依存関係をインストールするのに効果があると思うものをすべて使用し、インストール後にパッケージ化することは間違いなく機能します。 .deb 。

テストにスナップショットを持つ仮想マシンを使用するのも良い選択です。