私は私の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)によって引き起こされる二重以外の同じリストが得られます。