Я знаю, что этот вопрос уже задавался, но я не принимаю ответ "вы можете ясно видеть пользовательские дополнения". Когда я добавляю ppa (чего я не делал годами), я нажимаю клавишу на клавиатуре с надписью "Enter", которая позволяет мне добавить пустую строку перед новой записью (я бы даже добавил пояснительный комментарий, но я технический писатель, так что ....). Мне нравится моя sources.confчистота и аккуратность.
/etc/apt/sources.d
Это значит, что мне придется анализировать полдюжины файлов вместо одного.
Насколько мне известно, нет «абсолютно» никаких преимуществ в наличии одного файла конфигурации по сравнению с 6 (для ясности, может быть, у вас их 3 или даже 2, не имеет значения... 1 все равно лучше 2).
Может ли кто-нибудь назвать рациональное преимущество? «Вы можете ясно видеть индивидуальные дополнения» — это оправдание бедняка.
Должен добавить, что я люблю перемены, однако ТОЛЬКО если они приносят пользу.
Редактировать после первого ответа:
Это позволяет новым установкам, которым требуются собственные репозитории, не искать в плоском файле данные, чтобы убедиться в отсутствии дублирующихся записей.
Теперь им приходится искать дубликаты в каталоге, а не в плоском файле. Если только они не предполагают, что администраторы ничего не меняют...
Он позволяет системному администратору легко отключить (переименовав) или удалить (удалив) набор репозиториев без необходимости редактирования монолитного файла.
Администратору приходится выполнять grep в каталоге, чтобы найти подходящий файл для переименования. Раньше он искал ОДИН файл и комментировал строку, однострочник sed для «почти» любого администратора.
Это позволяет сопровождающему пакет отдать простую команду на обновление местоположений репозиториев, не беспокоясь о непреднамеренном изменении конфигурации для несвязанных репозиториев.
Я не понимаю этого, я "предполагаю", что мейнтейнер пакета знает URL своего репозитория. Опять же, это sedкаталог, а не один файл.
решение1
Размещение каждого репозитория (или набора репозиториев) в отдельном файле упрощает управление как вручную, так и программно:
- Это позволяет новым установкам, которым требуются собственные репозитории, не искать в плоском файле данные, чтобы убедиться в отсутствии дублирующихся записей.
- Он позволяет системному администратору легко отключить (переименовав) или удалить (удалив) набор репозиториев без необходимости редактирования монолитного файла.
- Это позволяет сопровождающему пакет отдать простую команду на обновление местоположений репозиториев, не беспокоясь о непреднамеренном изменении конфигурации для несвязанных репозиториев.
решение2
На техническом уровне, как человек, которому приходилось иметь дело с этими изменениями в нескольких крупных и популярных инструментах системной информации, могу сказать, что в основном все сводится к следующему:
Для 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
Обратите внимание, что если они не выполняют ту же проверку, что и ниже, если вы закомментировали строку репозитория, эти тесты будут неверными. Если они выполняют ту же проверку, что и ниже, то это та же самая сложность, за исключением того, что она выполняется для многих файлов, а не для одного. Кроме того, если они не проверяют ВСЕ возможные файлы, они могут, и часто делают, добавить дубликат элемента, на который затем apt жалуется, пока вы не удалите один из них.
Для источников.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
Разработчики Google Chrome не проверяли наличие исходников Google Chrome, полагаясь на точное имя файла, которое их пакет Chrome создаст для присутствия. Во всех остальных случаях они создавали новый файл в sources.list.d, названный именно так, как им хотелось.
Конечно, посмотреть, какие у вас есть источники, не так уж и приятно, поскольку нет ничего проще для чтения и поддержки, чем:
cat /etc/sources.list
Так что это было сделано в основном для целей автоматизированных обновлений и для предоставления простых отдельных команд, которые вы могли бы давать пользователям, насколько я могу судить. Для пользователей это означает, что им придется прочитать много файлов вместо одного, чтобы увидеть, добавлен ли у них репозиторий, а для apt это означает, что ему также придется прочитать много файлов вместо одного.
Так как в реальном мире, если вы собираетесь сделать это хорошо, вам придется поддерживать проверки всех файлов, независимо от их имен, а затем проверять, требуется ли выполняемое действие или нет.
Однако, если вы не собираетесь делать это хорошо, вы просто игнорируете проверки, чтобы увидеть, есть ли элемент где-то в источниках, и просто проверяете имя файла. Я думаю, что это то, что делает большинство автоматизированных вещей, но поскольку в конце концов мне просто пришлось проверить все, чтобы я мог перечислить это и действовать на основе того, совпал ли один из этих файлов, единственным реальным результатом было то, что все стало намного сложнее.
Массовые правки
Учитывая, что у меня запущено много серверов, я бы поддался соблазну просто написать сценарий для ночной работы, которая будет проходить по /etc/apt/sources.list.d/ и сначала проверять, нет ли элемента в sources.list, а затем, если его там нет, добавлять этот элемент в sources.list, удалять файл sources.list.d, а если он уже есть в sources.list, просто удалять файл sources.list.d.
Поскольку в использовании только sources.list нет НИКАКИХ недостатков, кроме простоты и удобства обслуживания, добавление чего-то подобного может оказаться неплохой идеей, особенно учитывая творческие случайные действия системных администраторов.
Как отмечено в комментарии выше, inxi -r аккуратно выведет активные репозитории по файлам, но, конечно, не будет их редактировать или изменять, так что это будет только половина решения. Если это много дистрибутивов, то изучение того, как каждый из них это делает, будет мучением, это точно, и случайность, безусловно, является правилом, а не исключением, как ни печально.
решение3
Если вы вручную управляете своими серверами, я соглашусь, что это все запутывает. Однако это приносит пользу программному управлению (т. е. "конфигурации как коду"). При использовании программного обеспечения для управления конфигурацией, такого как Puppet, Ansible, Chef и т. д., проще просто перетащить или удалить файл в каталог и запустить apt update, вместо того, чтобы анализировать файл, чтобы добавить или удалить определенные строки.
Тем более, что это позволяет избежать необходимости управлять содержимым одного «файлового» ресурса, например:, /etc/apt/sources.listиз нескольких независимых модулей, написанных третьими лицами.
Именно по этой причине я ценю широкое использование в Ubuntu каталогов «.d», т. е. sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d и т. д.
решение4
Это позволяет пакетам добавлять дополнительные источники, не прибегая к скриптам.
Например, при установке пакета Skype от Microsoft источник skype.com автоматически настраивается на загрузку обновлений; удаление пакета Skype из системы также снова отключает этот источник пакетов.
Если бы вы хотели добиться того же эффекта с помощью простого файла, то скриптам установки Skype пришлось бы изменить ваш sources.list, что, вероятно, многих системных администраторов немного расстроило бы.