☰

Guixで、マニフェストのどのパッケージが設定ファイルに特定の依存関係を追加するかを確認する方法は？

tag-icon • tag-icon guix guixsd
Guixで、マニフェストのどのパッケージが設定ファイルに特定の依存関係を追加するかを確認する方法は？

私は私のGuixシステムを完全に宣言的にしました、そして常にguix package -m mymanifest.scm。

依存関係の競合により失敗することもあります。たとえば、gcc-toolchainマニフェストに数十の異なるパッケージがあり、次のメッセージが表示されます。

guix package: error: profile contains conflicting entries for gcc-toolchain
guix package: error:   first entry: [email protected] /gnu/store/rfm800pq3q2midj29a4xlikdzjp1ps2l-gcc-toolchain-12.3.0
guix package: error:   second entry: [email protected] /gnu/store/ks87cpc36kh8hqwr569pks4yrzfl7mnv-gcc-toolchain-11.3.0
hint: You cannot have two different versions or variants of `gcc-toolchain' in the same profile.

gcc-toolchainマニフェストに含まれるものは12.3.0で、他のパッケージには[email protected]（間接）依存関係があるようです。ところで、それがどんなバッグなのか分からない。

gccこの特別な場合には、警告を発生させたマニフェストにも含め、これをpackage 'gcc' has been superseded by 'gcc-toolchain'削除するとgcc問題が解決したように見えるため、問題は簡単に解決されました。

しかし、「問題のある」パッケージを見つけるために、より一般的に適用可能な方法が必要です。つまり、たとえばマニフェストファイルがある場合、特定のパッケージ（たとえば、）がどの依存関係チェーンを介して設定ファイルに含まれているかをmymanifest.scmどうやって知ることができますか？[email protected]

私は通常、バイナリ検索を実行し、パッケージの半分だけコメントアウト（または返す）し、問題が消える（または再び表示される）時期を確認しますが、これは受動的で退屈なプロセスです。

私が直接自動化することができる醜くて素朴な方法は、すべてのパッケージを繰り返し、guix graph各パッケージを呼び出して、問題のある依存関係をgrepすることです。より良いアイデアは、実行中の作業を特定し、リストguix graph全体に対して行うことです。または、マニフェストをパッケージ（依存関係を除いて空）に変換してから呼び出すこともできますguix graph。しかし、より良い方法があるかもしれません。

ベストアンサー1

要約すると、マニフェストのサブセットを個別に構築し、guix build -m manifest.scm各マニフェストにリストされているパッケージのリポジトリアドレスから取得し、それを繰り返して、grepを使用してguix gc --requisites再帰的な依存関係を取得することで、一時的に競合を防ぐことができます。

現在のプロファイルの作成に失敗したため、追加する新しいパッケージと競合する古いパッケージを分離する必要があります。または、新しいパッケージで競合が発生した場合は切り離します。パッケージがどのように配布されるかは問題ではありません。重要なのは、確認したいすべてのパッケージがストアに正常にインストールされ（使用できるようにguix gc --requisites）、プログラムでそのパスをインポートできるいくつかのマニフェストがあることです。

guix build正常に構築されたことを確認し、コンパイルログの解析を処理する必要がないようにするには、まず各マニフェストでそれを実行します。次に、2番目はマニフェストに含まれるパッケージへのパスのみを出力します。

$ guix build -m manifest.scm
/gnu/store/jsk7igg8kd48blg5d6psb0rg120v68gw-xdot-1.1
/gnu/store/4dzv8avq7jyzybqvn3bj3c3bildi2pcc-graphviz-7.0.1-doc
/gnu/store/vsnrha979rs4sgmv2ynqvzd9dr5mj2mc-graphviz-7.0.1

その後、各パッケージを呼び出してこのリストを繰り返して、関心のある依存guix gc --requisites関係を検索できます（エラーメッセージに示すようにリポジトリの名前）。例は次のとおりですfish。

for manifest in manifest1.scm manifest2.scm
    for package in (guix build -m $manifest)
        if guix gc -R $package | grep -q '/gnu/store/ks87cpc36kh8hqwr569pks4yrzfl7mnv-gcc-toolchain-11.3.0'
            echo $package
        end
    end
end

マニフェストのすべてのパッケージを繰り返し一覧表示します[email protected]。

質問と直接関係がないかもしれませんが、完全性のために次のことを行います。

すでにストア内のプロファイルの依存関係を検索する必要がありますが、使用できない、または使用したくない場合guix build（マニフェストがない場合、またはguixがGBビルドを再ダウンロードする必要がある場合）ツールなど）：プロファイルパッケージリストからソースを復元することもできます。

通常、プロファイルがガベージコレクションされていない場合は、そのプロファイルへのリンクがあります/var/guix/profiles/per-user/。使用済みの構成ファイル（競合するパッケージなしで最後に正常にビルドされた）を探している場合は、guix package -m mymanifest.scmストアでアドレスを見つけることができます。

$ readlink -f ~/.guix-profile
/gnu/store/…-profile

設定ファイルへのパスがある場合、2番目のステップは元のマニフェストでパッケージパスを見つけることです。guix gc --references /gnu/store/…-profileまた、これに対するいくつかの依存関係がリストされているようです。明示的にインストールしたパッケージのみをインポートするには、パッケージリストのインデントを使用することをお勧めします/gnu/store/…-profile/manifest。最初のレベルのパッケージには6つのスペース、依存関係には10のパッケージなどがあります。

grep -E '^ {6}"/gnu/store/' /gnu/store/…-profile/manifest | cut -d'"' -f 2

guix buildその後、複数の出力を持つパッケージ（たとえば、上記の例のgraphviz）によって引き起こされる二重以外の同じリストが得られます。

おすすめ記事