소프트웨어를 빌드할 때 패키지를 빌드하는 데 필요한 라이브러리, 바이너리 등만 설치해야 하는 경우가 있는데, 제거하는 것을 잊어버려서 그렇지 않은 패키지도 한 번에 여러 개 정리해야 하는 경우가 있습니다. 제거하고 싶습니다.
정확한 패키지를 찾기 위해 로그 파일을 구문 분석하는 것은 최적이 아니며 패키지가 충분히 오래된 경우 큰 고통이 될 수 있습니다. 이 작업을 용이하게 하는 방법이 있습니까?
답변1
나는 이 문제에 도움이 될 aptitude(apt 바이너리에는 이 기능이 없음)의 기능인 사용자 태그를 사용하는 것이 좋습니다. 패키지를 설치할 때 --add-user-tag옵션을 추가합니다. 예:
sudo aptitude --add-user-tag build-dep-package build-dep package
삭제하려면 다음을 사용하세요.
sudo aptitude remove '?user-tag(build-dep-package)'
삭제 태그를 사용할 수도 있습니다 --remove-user-tag build-dep-package.
하지만 이로 인해 문제가 발생합니다. 동일한 패키지에 두 개의 태그가 있으면 어떻게 될까요? 음, 이런 일이 발생하는 것을 방지하려면 and/not 조건을 사용하면 됩니다.
sudo aptitude remove '?and(?user-tag(build-dep-package),?not(?user-tag(wanted-packages))'
라벨이 서로 다른 여러 패키지에 대해 작업하려면 다음을 사용하세요.
sudo aptitude remove '?or(?user-tag(build-dep-package),?user-tag(wanted-packages)'
이는 장기적으로 매우 유용합니다. 현재 활성화된 모든 태그를 나열하는 방법을 찾지 못했습니다.
답변2
블로그 게시물에서 David Kalnischkies의 게시물을 찾았습니다. UNDO APT-GET BUILD-DEP(빌드 종속성 제거)
모르는 분들을 위해 말씀드리자면 David는 2009년경부터 주요 관리자로 활동해왔기 때문에 그가 무슨 말을 하는지 알고 있을 것입니다.
돈쿨트 • 3년 전
이 미친 명령줄 작업을 시도하기 전에 다음 옵션을 사용해 보십시오: APT::Get::Build-Dep-Automatic
apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2 …
이것이 효과가 있고 영구적으로 유지하려는 경우: echo APT::Get::Build-Dep-Automatic "true" > /etc/apt/apt.conf.d/99markbuilddepauto
어떤 APT 버전에 추가되었는지는 기억나지 않지만 최소한 몇 개의 우분투 버전에서 사용할 수 있을 만큼 오래됐음에 틀림없습니다... 그런데: 2009년 2월 9일에 우분투에서 기본값이 "false"로 전환되었습니다.
아, 기록으로만 말씀드리자면 정말 말도 안되는 일입니다. 왜냐하면 APT와 함께 제공되는 설치 프로그램 앱이 이미 제공하는 apt-mark와 동일한 기능을 사용하기 위한 적성을 설치하기 때문입니다.
하지만 언제나 그렇듯, 6시간의 코딩으로 5분 동안 매뉴얼 페이지를 읽지 않아도 됩니다...
그래서,
apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2...
아마도 합리적인 접근 방식 일 것입니다. 이 옵션이 존재하는지 몰랐습니다. 현재로서는 적절한 문서에서 찾을 수 없습니다. 혹시 있으면 업데이트하겠습니다.
그러나 데비안 버그 보고서도 참고하세요.적성: APT::Get::Build-Dep-Automatic이 존중되지 않습니다.. 제목이 모든 것을 말해줍니다.
업데이트: 테스트 후 작동하지 않는 것 같습니다. 내가 해냈어
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true g++
그런 다음
# apt-get autoremove
그러나 아무것도 반환하지 않습니다. 어쩌면 내가 뭔가를 놓친 것 같습니다. 지금은 이 답변을 유지하겠습니다.
/var/lib/apt/extended_states업데이트 2: 패키지에 태그가 올바르게 지정되어 있는 것을 확인했습니다 Auto-Installed: 1. 따라서 autoremove잘못 사용하고 있는 것 같습니다.
업데이트 3: 시도함
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true coreutils
그리고 이번에는
# apt-get autoremove
올바르게 제거되었습니다 dh-buildinfo gperf libacl1-dev libattr1-dev.
그렇다면 왜 이전 시도는 성공하지 못했을까요? 확실하지는 않지만 최상위 패키지가 수동으로 설치된 패키지에 필요한 더미 패키지를 제공한다고 가정합니다. 그래서
gcj-jre-headless
Provides: java-gcj-compat-headless, java-runtime-headless, java-virtual-machine, java1-runtime-headless, java2-runtime-headless, java5-runtime-headless
그리고
ant
Depends: default-jre-headless | java5-runtime-headless | java6-runtime-headless | java7-runtime-headless, libxerces2-java
그래서 여기에 중복되는 부분이 있습니다 java5-runtime-headless. 즉 . 결론 - 이는 불행한 선택의 예일 수 있습니다.
답변3
이는 기존 개발 패키지에 도움이 되지 않지만 나중에 사용하려면 ( 패키지 mk-build-deps에서 )을 사용하여 종속성에 대한 메타 패키지를 생성하는 것을 고려하세요.devscripts
mk-build-deps사용 가능한 패키지 또는 해당 제어 파일의 이름만 필요합니다. 후자는 패키지를 아직 사용할 수 없거나 새 종속성을 추가하는 경우 유용합니다.
필요한 경우 생성된 메타패키지(및 종속성)를 설치할 수 있습니다.
평소와 같이 설치 후 매뉴얼 페이지에서 자세한 내용을 확인할 수 있습니다.