프로그램 추적

간단한 프로그램을 설치할 때 자주 사용 make && make install하며 제거 대상 이없는 경우가 많습니다 .

프로그램을 업그레이드하려면 이전 프로그램을 완벽하게 다시 작성한다고 가정하는 것이 표준 프로토콜입니까?

이 프로그램을 어떻게 추적합니까? 대부분의 사람들은 단지 '화재와 잊어 버리기' 만하고 제거 대상이 없으면 수동으로 모든 것을 삭제해야합니까?

전용 디렉토리 트리에 각 프로그램을 설치하고 Stow 또는 XStow 를 사용하여 모든 프로그램을 공통 계층 구조로 표시하십시오. Stow는 프로그램 별 디렉토리에서 공통 트리로 심볼릭 링크를 만듭니다.

보다 자세하게는 최상위 디렉토리를 선택하십시오 (예 :) /usr/local/stow. 아래에 각 프로그램을 설치하십시오 /usr/local/stow/PROGRAM_NAME. 예를 들어,에 실행 파일을 설치 /usr/local/stow/PROGRAM_NAME/bin하고 매뉴얼 페이지 등을 설치하십시오 /usr/local/stow/man/man1. 프로그램이 autoconf를 사용하는 경우을 실행하십시오 ./configure --prefix /usr/local/stow/PROGRAM_NAME. 을 실행 한 후 다음을 make install실행하십시오 stow.

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

이제 다음과 같은 기호 링크가 있습니다.

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

stow디렉토리 의 내용을 나열하여 설치 한 프로그램을 쉽게 추적 할 수 있으며 파일이 해당 프로그램의 디렉토리 아래 위치에 대한 심볼릭 링크이기 때문에 파일이 속한 프로그램을 항상 알고 있습니다. stow -D PROGRAM_NAME프로그램의 디렉토리 를 실행 하고 삭제하여 프로그램을 제거하십시오 . 프로그램을 stow -D PROGRAM_NAME실행 stow PROGRAM_NAME하여 일시적으로 사용할 수 없게 만들 수 있습니다 (다시 실행 하도록 실행 ).

동일한 프로그램의 다른 버전간에 빠르게 전환 /usr/local/stow/PROGRAM_NAME-VERSION하려면 프로그램 디렉토리로 사용 하십시오. 버전 3에서 버전 4로 업그레이드하려면 버전 4를 설치 한 다음을 실행하십시오 stow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4.

구 버전의 Stow는이 답변에서 설명한 기본 사항을 크게 뛰어 넘지 않습니다. 능력과 같은 고급 기능을 (최근에 유지되지 않은)가 최신 버전뿐만 아니라 XStow은 스토우 디렉토리 (예 : 외부의 기존 심볼릭 링크에 대처 더 나은, 특정 파일을 무시 man -> share/man(때 두) 자동으로 약간의 충돌을 처리 프로그램은 같은 파일을 제공합니다) 등

루트 액세스 권한이 없거나 사용하지 않으려는 경우 홈 디렉토리에서 디렉토리를 선택할 수 있습니다 (예 :) ~/software/stow. 이 경우에 추가 ~/software/bin하십시오 PATH. 경우 man자동으로 man 페이지를 찾을 수없는, 추가 ~/software/man사용자에 MANPATH. 추가 ~/software/info당신에게 INFOPATH, ~/software/lib/python당신에게 PYTHONPATH, 그래서 해당되는 경우에.

checkinstall 을 사용하여 패키지 (RPM, Deb 또는 Slackware 호환 패키지)를 만들 수 있습니다. 이렇게하면 배포 패키지 관리자를 사용하여 응용 프로그램을 추가 / 제거 할 수 있지만 업데이트는 할 수 없습니다

당신은 사용 checkinstall의 장소에서 make install(뎁의 -D 매개 변수를 사용하여, -R은 RPM이며 -S 슬렉웨어입니다) 명령 :

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstall은 기본적으로 패키지를 빌드 및 설치하거나 설치하지 않고 패키지를 빌드하도록 할 수 있습니다.

checkinstall은 대부분의 배포 저장소에서 사용할 수 있습니다.

대부분의 경우, 패키지, 포트 및 기타 유형의 관리자가이 유형의 일이 발생하지 않도록하는 이유가되었습니다.

다른 사람이 내가 알지 못하는 그 시점에 대한 더 나은 대답이 없다면 수동 삭제는 수동 설치의 유일한 방법이라고 말할 수 있습니다.

또 다른 대안은 Linux From Scratch 힌트입니다 .

패키지 사용자를 통한 더 많은 제어 및 패키지 관리

3 패키지 사용자
3.1 소개

이 체계의 기본 아이디어는 쉽게 설명됩니다. 모든 패키지는 특정 "패키지 사용자"에 속합니다. 패키지를 설치할 때 패키지를이 패키지 사용자로 빌드하고 설치하면 설치된 모든 파일이 패키지 사용자가 소유하게됩니다. 결과적으로 모든 일반적인 패키지 관리 작업은 표준 명령 줄 유틸리티를 사용하여 편안하게 수행 할 수 있습니다. ls -l <file>예를 들어 어떤 패키지가 <file>속 하는지 간단 하게 알려 주면 find -user ...명령을 통해 특정 패키지에 속하는 모든 파일에 대해 작업을 수행 할 수 있습니다 (예 : 패키지를 제거하기 위해 삭제).

그러나 패키지 관리가 패키지 사용자에게 적합한 것은 아닙니다. 패키지 사용자에게는 루트 권한이 없으므로 패키지 설치가 수행 할 수있는 작업으로 제한됩니다. 예를 들어, 패키지 사용자가 할 수없는 한 가지는 다른 패키지 사용자의 파일을 덮어 쓰는 것입니다. 같은 이름의 바이너리, 라이브러리 또는 헤더 파일을 설치하려는 다른 패키지 간의 충돌이 생각보다 일반적입니다. 패키지 사용자의 경우 패키지 B를 설치해도 알리지 않고 패키지 A에서 파일을 자동으로 파괴 할 위험이 없습니다. 패키지 B를 설치하는 동안이 작업을 수행 할 때마다 "권한 거부"또는 "작업이 허용되지 않음"오류가 발생하여 적절한 단계를 수행 할 수 있습니다. 패키지 사용자가 할 수없는 또 다른 것은 setuid 루트 바이너리를 설치하는 것입니다. 바이너리 setuid 루트를 만들기로 한 결정은 신중한 관리자가 소프트웨어 패키지 제작자에게 맡기고 싶지 않은 것입니다.

일반적으로 패키지 사용자 계정에는 유효한 비밀번호가 없으므로 루트 su 사용자 만 패키지 사용자가 액세스 할 수 있으므로 패키지 사용자가 시스템에 추가 방법을 열거 나 보안을 약화시키지 않습니다. 하지만 당신은 할 수 있습니다 설치하고 실제 루트 계정에 액세스하지 않고 이렇게하는 특정 소프트웨어 패키지를 관리 할 수 있도록하려면 공동 관리를 할 수 있도록 어쨌든 암호를 설정합니다. 이 공동 관리자는 예를 들어 작업 그룹에 필요할 수있는 추가 라이브러리를 설치, 삭제 및 변경할 수 있습니다. 그러나 libc와 같이 자신이 소유하지 않은 라이브러리를 제거하거나 수정할 수 없습니다.

이 첫 번째 원유 제안 후, 나는 진화 된 변형을 발견했습니다.

crablfs-사용자 기반 패키지 관리 시스템

이것은 crablfs패키지 관리를 위해 고유 한 uid 및 gid를 사용하는 최신 패키지 관리 표본이지만 sourceforge에서는 다시 ulfs로 발전하고 있습니다.

uLFS : 스크래치에서 관리 및 재사용 가능한 Linux

설치된 패키지의 인과적인 사용자에게는 "패키지 사용자"LFS 솔루션이 가볍고 덜 침습적이며 우아하다고 생각합니다. 즉, 당신은에서 패키지를 설치 /usr/local하거나 /home/user/local각 패키지의 고유 한 UID 및 GID를 사용하여 파일을 추적하지만, 전통적인 장소, 공통의 디렉토리에있는 모든 파일을 넣어 /usr/local/bin, /usr/local/lib그것은 모든 주요 리눅스 배포판처럼 ... 파일 폐색 및 원치 않는 파일 덮어 쓰기 또는 삭제 Matthias S. Benkmann에 의해 more_control_and_pkg_man.txt에 설명 된 깔끔한 Linux 트릭에 의해 피할 수 있습니다. more_control_and_pkg_man.txt는 일반적인 파일 및 디렉토리 권한 조작 만 필요합니다.

3.3 그룹

모든 패키지 사용자는 2 개 이상의 그룹에 속합니다. 이러한 그룹 중 하나는 모든 패키지 사용자 (및 패키지 사용자 만)가 속하는 "install"그룹입니다. 패키지가 물건을 설치할 수있는 모든 디렉토리는 설치 그룹에 속합니다. 여기에는 / bin 및 / usr / bin과 같은 디렉토리가 포함되지만 / root 또는 /와 같은 디렉토리는 제외됩니다. 설치 그룹이 소유 한 디렉토리는 항상 그룹 쓰기 가능합니다. 이것은 패키지 관리 측면에 충분하지만 추가 준비가 없으면 모든 패키지가 다른 패키지의 파일을 대체 할 수 있기 때문에 추가 보안 또는 제어 기능을 제공하지 않습니다 (변경 내용은ls -l그러나). 이러한 이유로 모든 설치 디렉토리는 sticky 속성을 갖습니다. 이를 통해 사용자는 새 파일을 작성하고 디렉토리에서 자신의 파일을 삭제하거나 수정할 수 있지만 다른 사용자의 파일은 수정하거나 제거 할 수 없습니다. 이 힌트의 나머지 부분에서 "install directory"라는 용어가 사용될 때마다 그룹 설치에 속하는 디렉토리를 나타내며 그룹 쓰기 가능하고 고정적입니다. IOW, <dir>설치 디렉토리 로 바꾸 려면

chgrp 설치 및 & chmod g + w, o + t

나를 위해 그것은 간단하고 영리한 솔루션처럼 보입니다! 내 LFS 빌드 에서이 체계를 사용했으며 작동하는 솔루션입니다 ...

1. 알림으로 빈 RPM을 만들 수 있습니다.
2. 소프트웨어를 RPM에 올바르게 배치하여 볼 수 있습니다.
3. tar설치에서 파일 사본을 남겨 두어 /usr/src/non-rpms알림을 표시 할 수 있습니다 (보통 내가하는 일).