주류 Linux 배포판(deb/apt, yum/dnf, pacman 등)의 기본 패키지 관리자는 기본적으로 전역적으로 설치되며 루트가 필요합니다. 사용자 또는 그룹으로 설치하고 루트가 필요하지 않은 경우 루트로 실행되는 신뢰할 수 없는 코드(예: Nix, Guix, Cargo, Pip, Gem, Cabal, Stack, CPAN)가 줄어들기 때문에 더 나은 것 같습니다.
공유 시스템의 공간을 절약하기 위해 사용자는 읽을 수 있고 관리자는 쓸 수 있는 디렉터리에 패키지를 설치할 수 있습니다. 하지만 루트일 필요는 없으며 사용자가 자신의 패키지를 설치할 수 있어야 합니다.
보호된 파일(예: Grub) 또는 제공 패키지를 수정하려면 루트 시스템을 수정해야 하지만 그 밖의 모든 작업은 사용자 측에서 가능해야 합니다.
이 문제해당 패키지는 파일 시스템 계층 구조의 특정 위치에 설치되어 있다고 가정할 수 있지만 이는 설정 및 친구를 통해 해결할 수 있다고 생각 $PATH합니다 $LD_LIBRARY_PATH. 그렇지 않으면 chroot에서 프로그램을 실행하는 래퍼를 갖는 것이 어떨까요?
답변1
당신 말이 맞아요시스템 패키지 관리자, 시스템 라이브러리와 공유 프로그램(및 데몬도 가능)을 설치하므로 루트 권한이 필요합니다.
일부가 있습니다사용자 공간 패키지 관리자, 예를 들어 flatpack이지만 살펴보면 다음과 같은 몇 가지 문제를 발견할 수 있습니다.
두 개(또는 그 이상)의 패키지 관리자를 배워야 하며 일부 프로그램이 어디에서 왔는지(시스템 또는 사용자?) 혼란스러울 수 있습니다.
종속성은 더 복잡합니다. 특정 수준의 패키지 관리자는 다른 패키지 관리자의 종속성을 볼 수 없습니다. 예를 들어 운영 체제 버전을 업그레이드하면 일부 사용자가 작동하지 않을 수 있으며 사용자가 설치한 모든 프로그램을 확인할 수 없습니다. 하지만 그 반대이기도 합니다. 내 사용자 공간 패키지 관리자는 시스템 패키지에 영향을 미칠 수 없습니다. 특정 버전의 패키지가 필요한 경우 해당 패키지가 필요하고, 그렇지 않으면 길을 잃습니다. 따라서 대부분의 이러한 사용자 공간 패키지에는 필요한 종속성(및 라이브러리)이 포함되는 경향이 있습니다.
이로 인해 하나의 시스템을 다루는 것이 훨씬 더 어려워집니다(두 시스템을 통합하는 방법을 찾는 경우).
참고: 컴퓨터 언어(가상 환경이 포함된 Python, node.js가 포함된 JavaScript 등)에는 라이브러리 및 기타 프로그램을 처리하기 위한 자체 시스템(패키지 관리자와 유사)이 있을 수 있습니다.
간단히 말해서, 어렵습니다. 요즘 우리는 일반적으로 docker를 선호합니다. 시스템과 컨테이너(그리고 단순한 경계: 파일 시스템, 네트워크)가 명확하게 구분되어 있습니다. 이제 우리는 사용자 패키지가 시스템에 잘 통합될 수 있도록 더 많은 지원(섀도우 파일 시스템, 독립 네임스페이스 등)을 갖게 되었지만 시스템 유지 관리가 용이하다는 문제는 실제로 해결되지 않고 사용자가 위험하게 실행될 수 있습니다. (취약한 프로그램 중 오래된 것). 지금은 가능할 수도 있다고 생각하지만, 그렇게 할 수요(또는 자원봉사자)가 많지 않습니다.
sl추신: 새 버전의 라이브러리를 설치하거나 , , 등 의 일부 프로그램을 설치하면(일반적인 명령의 철자가 틀리는 경우) 다른 사용자를 혼란스럽게 할 수 있습니다. les이러한 사용자의 모든 권한을 쉽게 얻을 수 있습니다.