存在するこの問題インストールコマンドの最終ターゲットのパッケージの検索中に発生した問題について説明しました/usr/bin/rename
。dpkg -S /usr/bin/rename
結果は出ませんでしたが、最初にそれがリンクであることを発見した後、一般的な解決策を見つけました。
/usr/bin/rename
それが/etc/alternatives/rename
私に方法を教えてくれるからこれ特定のリンクはadminによって管理されますupdate-alternatives
。
この知識がなければ、どのパッケージが実際にシンボリックリンクをインストールしているのかをどうやって知ることができますか?これを行うための単純なコマンドがない場合、どのコマンドがシンボリックリンクを確立するかを見つけるための一般的な戦略は何ですか?
答え1
dpkg -S
シンボリックリンクはパッケージから抽出されたファイルのみを表示するため、どのパッケージがインストールされているかを知る方法はありません。この情報はのマニュアル*.list
で/var/lib/dpkg/info/*.list
。
Debianシステムの各ファイルは1つのパッケージでのみ所有できます。インストールするパッケージに他のパッケージによってすでに提供されているファイルが含まれている場合は、次のいずれかが発生します。
dpkg
2番目のパッケージのインストールは拒否されます。dpkg
2番目のパッケージがインストールされる前に最初のパッケージが削除されます(2番目のパッケージがBreaks
最初のパッケージとOR関係を指定した場合)。Conflicts
dpkg
2番目のパッケージをインストールする前に、ファイルを提供しなくなった最新バージョンに最初のパッケージをアップグレードしてください(2番目のパッケージが/および1番目のパッケージConflicts
とBreaks
の関係を指定している場合)。Replaces
dpkg
2番目のパッケージは最初のパッケージと共にインストールされ、2番目のパッケージによって提供されるファイルで上書きされます(2番目のパッケージがReplaces
最初のパッケージの関係を指定する場合)。
明らかに、これは実際には複数のパッケージに同じコマンドが与えられ、同時にインストールされることを許可しません。alternatives
Debian システムこれらのパッケージはファイルに異なる名前を提供します。たとえば、次のようになります。
host ~ # dpkg -S /usr/bin/prename
perl: /usr/bin/prename
パッケージpostinst
スクリプト(/var/lib/dpkg/info/perl.postinst
)はそれを代替として登録します。
# util-linux has an alternate rename
update-alternatives --install /usr/bin/rename rename /usr/bin/prename 60 \
--slave /usr/share/man/man1/rename.1.gz rename.1.gz \
/usr/share/man/man1/prename.1.gz
dpkg -S
だから知られていません/usr/bin/rename
。
この知識がなければ、どのパッケージが実際にシンボリックリンクをインストールしているのかをどうやって知ることができますか?
Debian パッケージできるシンボリックリンクを提供するので、シンボリックリンク(または他の理由で生成されたシンボリックリンク)でない限り、alternatives
正常に機能します。postinst
dpkg -S
システムの場合は、alternatives
シンボリックリンクパスに従ってください。
host ~ # dpkg -S $(readlink -f /usr/bin/rename)
perl: /usr/bin/prename
もちろん、これは間違った結論につながる可能性があります。たとえば、パッケージがpostinst
別のファイルによって提供されるファイルへのシンボリックリンクを生成する場合です。この場合、責任あるパッケージを見つけるための一般的な方法はありません。ファイルにgrep
pingを送信するなど、いくつかの検索操作を実行する必要があります。*.postinst