/etc/apt/sources.list에 비해 /etc/apt/sources.list.d의 장점은 무엇입니까

이 질문이 이전에 요청 된 것을 알고 있지만 "사용자 지정 추가 사항을 명확하게 볼 수 있습니다"라는 대답을 받아들이지 않습니다. ppa 's를 추가 할 때 (몇 년 동안하지 않은) 키보드에 "Enter"라고 적힌 키를 누르면 새 항목 앞에 빈 줄을 추가 할 수 있습니다. 기술 작가, 그래서 ....). 나는 sources.conf깨끗하고 깔끔합니다.

/etc/apt/sources.d

하나의 파일 대신 파싱 할 파일이 6 개 있다는 것을 의미합니다.

AFAIK, 하나의 구성 파일 대 6을 갖는 것에는 "절대적으로"이점이 없습니다 (논쟁을 위해, 아마도 3 또는 2가있을 수도 있습니다 ... 1은 여전히 ​​2를 이깁니다).

누군가가 합리적인 이점을 생각해 낼 수 있습니까? "사용자 정의 추가 사항을 명확하게 볼 수 있습니다"는 가난한 사람의 변명입니다.

그러나 변경으로 인해 혜택이 생기는 경우에만 변경을 추가해야합니다.

첫 번째 응답 후 편집 :

자체 저장소가 필요한 새 설치에서 플랫 파일을 검색하지 않아도 중복 항목이 추가되지 않도록 할 수 있습니다.

이제 플랫 파일 대신 디렉토리에서 듀프 파일을 검색해야합니다. 관리자가 변경하지 않는다고 가정하지 않는 한 ...

시스템 관리자는 모 놀리 식 파일을 편집하지 않고도 리포지토리 세트를 쉽게 비활성화 (이름 변경) 또는 제거 (삭제) 할 수 있습니다.

관리자는 이름을 바꾸기 위해 적절한 파일을 찾기 위해 디렉토리를 grep해야합니다. 이전에 그는 한 파일을 검색하고 한 관리자 인 "거의"한 줄짜리 줄을 주석 처리했습니다.

패키지 관리자는 관련없는 리포지토리의 구성을 실수로 변경하지 않아도 리포지토리 위치를 업데이트하는 간단한 명령을 제공 할 수 있습니다.

나는 이것을 이해하지 못한다. 나는 패키지 관리자가 자신의 저장소의 URL을 알고 있다고 가정한다. 다시, sed단일 파일 대신 디렉토리에 있어야 합니다.

기술적 인 측면에서 볼 때 몇 가지 크고 인기있는 시스템 정보 도구에서 이러한 변경 사항을 처리해야하는 사람은 기본적으로 다음과 같습니다.

sources.list.d /

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

아래와 동일한 확인을 수행하지 않으면 리포지토리를 주석 처리 한 경우 이러한 테스트가 잘못 될 수 있습니다. 그들이 아래와 같은 검사를하고 있다면, 하나의 파일이 아닌 많은 파일에 대해 수행되는 것을 제외하고는 똑같은 복잡성입니다. 또한 모든 가능한 파일을 확인하지 않는 한 중복 항목을 추가 할 수 있으며, 그 중 하나를 삭제할 때까지 해당 항목에 대해 불만을 제기 할 수 있습니다.

sources.list의 경우

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Chrome 개발자는 Chrome 패키지가 존재하기 위해 생성 한 정확한 파일 이름을 사용하여 Chrome 소스가 있는지 확인하지 않았습니다. 다른 모든 경우에, 그들은 원하는 방식으로 이름이 지정된 새로운 파일을 sources.list.d에 작성합니다.

물론 어떤 소스를 가지고 있는지 알기 위해서는 다음보다 읽기 쉽고 유지하기가 쉽지 않기 때문에 그리 좋지 않습니다.

cat /etc/sources.list

따라서 이것은 기본적으로 자동화 된 업데이트를 목적으로 수행되었으며, 내가 알 수있는 한 사용자에게 제공 할 수있는 쉬운 단일 명령을 제공하기 위해 수행되었습니다. 사용자에게는 리포지토리가 추가되었는지 확인하기 위해 1 개의 파일 대신 많은 파일을 읽어야하며, apt의 경우 하나의 파일 대신 많은 파일을 읽어야한다는 의미입니다.

실제 환경에서이 작업을 제대로 수행하려면 파일 이름에 관계없이 모든 파일에 대한 검사를 지원 한 다음 수행 할 조치가 필요한지 테스트해야합니다.

그러나 제대로 수행하지 않으려면 항목이 소스에 있는지 확인하는 검사를 무시하고 파일 이름 만 확인하십시오. 나는 그것이 가장 자동화 된 것들이라고 생각하지만, 결국에는 모든 것을 확인하여 파일을 나열하고 해당 파일 중 하나가 일치하는지에 따라 행동 할 수 있었을 때 유일한 결과는 훨씬 더 복잡하게 만들었습니다.

일괄 수정

많은 서버를 실행하면 /etc/apt/sources.list.d/를 통해 반복되는 야간 작업을 스크립팅하고 항목이 이미 sources.list에 없는지 확인한 다음 야간에 작업을 수행하려고합니다. 해당 항목을 sources.list에 추가하고 sources.list.d 파일을 삭제하십시오. 그리고 이미 sources.list에있는 경우 sources.list.d 파일을 삭제하십시오.

단순성과 유지 보수 용이성을 넘어서 source.list 만 사용하는 것은 부정적인 일이 아니기 때문에 이와 같은 것을 추가하는 것은 좋지 않은 생각이 아닐 수 있습니다.

위의 주석에서 언급했듯이 inxi -r은 파일 당 활성 저장소를 깔끔하게 인쇄하지만 물론 편집하거나 변경하지 않으므로 솔루션의 절반에 불과합니다. 분포가 많으면 각각 어떻게 작동하는지 배우는 것은 고통 스럽습니다. 확실히, 그리고 무작위성은 확실히 예외가 아니라 규칙입니다.

각 리포지토리 (또는 리포지토리 모음)를 자체 파일에 저장하면 손으로 또는 프로그래밍 방식으로 관리하기가 더 간단 해집니다.

• 자체 저장소가 필요한 새 설치에서 플랫 파일을 검색하지 않아도 중복 항목이 추가되지 않도록 할 수 있습니다.
• 시스템 관리자는 모 놀리 식 파일을 편집하지 않고도 리포지토리 세트를 쉽게 비활성화 (이름 변경) 또는 제거 (삭제) 할 수 있습니다.
• 패키지 관리자는 관련없는 리포지토리의 구성을 실수로 변경하지 않아도 리포지토리 위치를 업데이트하는 간단한 명령을 제공 할 수 있습니다.

수동으로 서버를 관리하는 경우 더 혼란 스럽습니다. 그러나 프로그램 관리 (예 : "코드로 구성")에 도움이됩니다. Puppet, Ansible, Chef 등과 같은 구성 관리 소프트웨어를 사용 apt update하는 경우 파일을 구문 분석하는 대신 특정 행을 추가하거나 제거하는 대신 dir에서 파일을 삭제하거나 삭제하고 실행하는 것이 더 쉽습니다 .

특히 /etc/apt/sources.list제 3자가 작성한 여러 개의 독립적 인 모듈에서 단일 '파일'리소스의 내용을 관리 할 필요가 없기 때문입니다 .

이 특별한 이유로 우분투의 ".d"dirs, 즉 sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d 등의 광범위한 사용에 감사드립니다.

로 니모는 의견에서 지적, 디렉토리의 주요 장점 중 하나는 "소유"의 개념을 가능하게합니다.

최신 Linux 배포판과 설치 프로그램은 모두 패키지 라는 아이디어를 기반으로합니다. 패키지 는 가능한 한 많이 추가하고 제거 할 수있는 독립적 인 소프트웨어입니다. 당신이 가진 패키지를 설치 할 때마다 dpkg(때문에 apt), 시스템에 파일이 설치 프로그램에 의해 생성 된 추적합니다. 패키지를 제거하면 대부분 해당 파일을 삭제하는 것으로 구성 될 수 있습니다.

현재 허용 대답은 구글 크롬 설치가 끔찍한 가장자리 모든 종류의 경우에 다른 리드를 생성하거나 예상 위치에서 항목을 삭제할 수 있지만 자동화 아무것도에만해야한다고 가정하는 나쁜 일이로한다; 예를 들어 :

• sources.list설치시 줄이 있지만 주석 처리 된 경우 설치 관리자가 주석을 해제하거나 복제본을 추가해야합니까?
• 설치 제거 프로그램이 행을 제거하지만 사용자가 옆에 주석을 추가하거나 편집 한 경우 파일은 주석이 끊어진 상태로 남아 있습니다.
• 사용자가 회선을 수동으로 추가 한 경우 설치 프로그램은 해당 회선을 추가하지 않을 수 있습니다. 그러나 제거 프로그램이 제거하지 않으려면 어떻게해야합니까?

소유권을 위해 별도의 파일이 필요하지 않습니다. 예를 들어, 설치 프로그램은 특정 행 세트를 "소유"한다는 주석 블록을 포함 할 수 있습니다. 이 경우 항상 동일한 리포지토리에 대한 다른 언급이 아닌 정확한 블록을 파일에서 검색합니다.

다른 모든 것이 동일하면 단일 구성 파일에 대한 편집 자동화는 별도의 파일 작성 및 삭제 자동화보다 항상 복잡합니다. 최소한 라인을 제거하려면와 같은 패턴 일치 도구를 사용해야합니다 sed. 보다 복잡한 파일에서 행을 추가하거나 제거하려면 파일 형식에 대한 지식이있는 스크립팅 도구가 필요하거나 적절한 섹션에 추가하거나 주변 서식을 손상시키지 않고 제거해야합니다.

어쨌든 설치 프로그램은 수동으로 편집 한 구성을 엉망으로 만들 필요가 없으므로 자동화 된 도구 소유 구성을 자동화 된 도구를 쉽게 관리 할 수있는 형식으로 배치하는 것이 좋습니다.

이를 통해 패키지는 스크립트에 의존하지 않고 소스를 추가 할 수 있습니다.

예를 들어 Microsoft의 Skype 패키지를 설치하면 skype.com의 소스가 자동으로 업데이트를 다운로드하도록 구성됩니다. 시스템에서 Skype 패키지를 제거하면이 패키지 소스도 다시 비활성화됩니다.

플랫 파일과 동일한 효과를 원한다면 Skype 용 설치 스크립트가 sources.list를 수정해야 할 것입니다. 많은 시스템 관리자가 약간 불안해 할 것입니다.

나는 그것이 유행처럼 보이는 것 이외의 좋은 이유가 있다고 확신하지 않습니다. 나에게 그것은 디렉토리가 잎이나 노드이어야한다는 규칙을 어긴 다.

필자는 파일이 더 작고 읽기가 더 쉽다고 생각합니다. 예를 들어 sudo 규칙의 경우 상당히 길 수 있지만 한 유형의 사용자 (예 : 개발자)에 대해 표준화 된 규칙 세트를 갖는 것이 더 쉽습니다. ), 개발자가이 머신에서 sudo를 허용해야한다면 config 디렉토리에 추가하십시오. 따라서 적은 수의 파일을 유지해야합니다. 가능한 모든 조합이 아닌 개발자, 관리자, sysops 등의 파일입니다.

나는 모순되었다.