나는 내 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
성공적으로 빌드되었는지 확인하고 컴파일 로그 구문 분석을 처리할 필요가 없도록 하려면 먼저 각 매니페스트에서 이를 실행하세요 . 그런 다음 두 번째에는 매니페스트에 포함된 패키지에 대한 경로만 출력합니다.
$ 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
구성 파일의 경로가 있으면 두 번째 단계는 원래 매니페스트에서 패키지 경로를 찾는 것입니다. 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)로 인해 발생하는 이중을 제외한 동일한 목록을 얻게 됩니다 .