ghc-pkg check
은 깨진 패키지를 나열하고 왜 고장 났는지 알기 쉽습니다. 그러나 내가 아는 한, 깨진 패키지를 처리하는 자동화 된 방법이 없습니다. 깨진 패키지를 처리하는 데 권장되는 방법은 무엇입니까? GHC를 다시 설치하지 않는 것이 좋습니다.ghc-pkg check에 언급 된 문제 해결
답변
글로벌 패키지 데이터베이스에서 문제가 발생하지 않았 으면 좋겠다. 파손은 쉽게 GHC의 재설치가 필요하다는 것을 의미 할 수 있습니다. 따라서 파손이 사용자 패키지 db로 제한되어 있다고 가정 해 봅시다 (사용자 패키지에 의해 전체적으로 섀도 잉 된 패키지 또는 패키지 2 개 제외). 단지 몇 가지 패키지가 깨진 경우, 잘못된 패키지를 등록 취소가 종종 borken 등록을 취소하는 것은 다른 패키지을 깰 것이라고 불평
$ ghc-pkg unregister --user borken
당신의 설정을 수정할 수 있습니다. 첫 번째 등록을 취소하거나 곧바로 --force
으로 등록 취소를 시도하든 나중에 새로 처리 된 것인지 처리하는 것은 대부분 선택의 문제입니다. 사용자 db의 패키지 만 등록 취소하십시오. 일이 너무 까다 롭지 않으면 소수의 패키지 등록을 취소 한 후에 ghc-pkg check
에 더 이상 손상된 패키지가보고되지 않습니다.
반면에 패키지의 상당 부분이 손상된 경우 사용자 db ($ rm -rf ~/.ghc/ghc-version/package.conf.d
) 또는 다른 OS에서 이에 해당하는 것을 완전히 지우는 것이 더 쉬울 것입니다.
어느 쪽이든, 여전히 사용하고 싶은 패키지를 잃어버린 것이므로 새로운 것을 깨지 않고 다시 설치하려고합니다. 당신이 cabal-install
에 설치된 모든 패키지에 대한 일관된 설치 계획을 생성하려고합니다
$ cabal install world --dry-run
를 실행합니다. 그렇게하지 않으면 그 이유가 인쇄 될 것입니다. 그러면 월드 파일 (
~/.cabal/world
)에 나열된 패키지에 제약 조건을 추가하여 문제를 해결할 수 있습니다. 예를 들어, 손상된 패키지가 없습니다 (예 : ghc/ghc-pkg),
cabal install world --dry-run
은 (
vector-0.7.1
이 설치되어 있음)에 따라
vector-algorithms-0.5.2
을 구성 할 수 없다고 말했습니다. 그 이유는
hmatrix-0.12.0.1
은
vector >= 0.8
이 필요하기 때문입니다. hmatrix의
-any
"제약 조건"을 world 파일의 "< 0.12"로 바꾸면 새로 설치 계획이 생겼습니다.
따라서 world 파일에서 제약 조건을 무시하고 조금만 지나치면 cabal의 설치 계획을 얻을 수 있습니다. 그 패키지가 이미 가지고있는 패키지를 다시 설치할 것인지 확인하십시오 (새 버전을 설치하는 것이 좋습니다. 같은 버전을 다시 설치하면 문제가 발생 함). 카발의 설치 계획에 만족한다면
cabal install world
과 GHC가 바쁜 동안 좋은 차 한잔을 양조하십시오. 다시
ghc-pkg check
을 실행하여 모두 순서대로 작동하는지 확인하십시오.
일반적으로 좋은 조언 : 패키지 설치가 무엇인지 알지 못하는 경우 은 항상 --dry-run을 먼저 사용합니다.
cabal로 글로벌 설치를 수행하여 글로벌 패키지 데이터베이스를 망가 뜨린 경우 범죄자 등록을 취소하는 전략이 효과적 일 수 있지만, 어떤 방법으로 고장이 났는지에 따라 ghc가 취소 될 수 있습니다. OS 배포판에서 패키지를 설치하여 글로벌 데이터베이스를 망가 트린 경우, 새로운 GHC를 설치하고 배포 패키지 작성자를 저주하고 이러한 이벤트를 방지하도록하십시오.
cabal repair
명령은 매우 좋지만, 당분간 깨진 설정을 복구하는 것은 훨씬 더 많은 작업입니다.
글로벌 패키지 데이터베이스가 고장났습니다. 패키지 관리자를 사용하거나 여러 사람의 컴퓨터를 관리하여 패키지를 전 세계적으로 설치하기 때문에 시스템 전반에 걸쳐 패키지를 설치하는 경우 문제를 해결할 필요가 있습니다. 비록 부트 패키지가 깨질 때 ** ** 문제입니다. – ivanm
예, 영향을받는 부트 패키지가 없으면 많은 차이가 없으며 사용자 db를 완전히 지울 수 있고 여전히/다시 작동하는 GHC를 가질 수 있습니다. 하지만 불행히도 부팅 패키지가 자주 영향을 받는다는 인상을 받았습니다. 전 세계적으로 설치하는 경우에는 특히주의하십시오. –
음, cabal-install을 사용하면 부트 패키지가 영향을받을 수 있지만 배포판 패키지 관리자를 사용하면 문제가되지 않습니다. – ivanm
잠시 동안 나는 이것을 ghc-pkg-clean script에 의존했습니다.모든 깨진 패키지를 제거하고 필요에 따라 다시 설치합니다. 더 심각한 파손의 경우 ghc-pkg-reset script을 사용합니다.
오늘은 더 이상 깨진 패키지가 깨지지 않도록 자동화 한 ghc-pkg-autofix을 발견했습니다. 나는 그것이 무엇인지 모르겠다. YMMV.
설명과 소스를 간략하게 살펴보면,'ghc-pkg-autofix'는'~/.ghc /.../ package.conf.d/package'의 의존성 정보를 재 작성합니다. 그것은 위험한 조작인데, 그것은 교활한 방법으로 물건을 깨뜨릴 수 있습니다. 그러나 그것이 작동하는 곳에서는 빠릅니다. descrition이 말했듯이, _ 당신 자신의 위험을 감수하십시오. 스크립트가 더욱 안전 해 보입니다. 그러나 당신이 나를 좋아하고 여러 개의 GHC를 설치했다면, ghc-pkg-clean은 ghc (ghc-pkg가 사용할 인수를 취하도록 스크립트를 수정하기 쉽다)와 ghc-pkg-reset 그들 모두를 핵무기로 만들 것입니다. 그래서, 나를 위해서가 아니라, 나는 이상합니다. +1 자동 도움말. –
이것은 패키지를 어떻게 설치 했느냐에 달렸습니다 ... – ivanm