Sei que esta pergunta já foi feita antes, mas não aceito a resposta: "você pode ver claramente as adições personalizadas". Quando adiciono ppa's (o que não faço há anos), pressiono uma tecla do meu teclado chamada "Enter" que me permite adicionar uma linha vazia antes da nova entrada (eu até adicionaria um comentário explicativo, mas sou um redator de tecnologia, então ....). Eu gosto do meu sources.conflimpo e arrumado.
/etc/apt/sources.d
Significa que tenho meia dúzia de arquivos para analisar em vez de apenas um.
AFAIK, não há "absolutamente" vantagem em ter um arquivo de configuração versus 6 (para fins de argumentação, talvez você tenha 3 ou mesmo 2, não importa ... 1 ainda vence 2).
Alguém pode encontrar uma vantagem racional, "você pode ver claramente os acréscimos personalizados" é uma desculpa de homem pobre.
Devo acrescentar que adoro mudanças, entretanto, SOMENTE quando há benefícios introduzidos pela mudança.
Editar após a primeira resposta:
Ele permite que novas instalações que precisam de seus próprios repositórios não precisem pesquisar um arquivo simples para garantir que ele não esteja adicionando entradas duplicadas.
Agora, eles precisam procurar em um diretório por ingênuos em vez de um arquivo simples. A menos que eles assumam que os administradores não mudam as coisas ...
Ele permite que um administrador de sistema desabilite (renomeando) ou remova (excluindo) facilmente um conjunto de repositórios sem precisar editar um arquivo monolítico.
O administrador precisa usar o diretório grep para encontrar o arquivo apropriado para renomear; antes, ele pesquisava UM arquivo e comentava uma linha, um sed one-liner para "quase" qualquer administrador.
Ele permite que um mantenedor de pacote forneça um comando simples para atualizar os locais dos repositórios sem ter que se preocupar em alterar inadvertidamente a configuração de repositórios não relacionados.
Eu não entendo isso, "presumo" que o mantenedor do pacote conheça a URL de seu repositório. Novamente, é necessário sedum diretório em vez de um único arquivo.
Responder1
Ter cada repositório (ou coleção de repositórios) em seu próprio arquivo torna mais simples o gerenciamento, tanto manual quanto programaticamente:
- Ele permite que novas instalações que precisam de seus próprios repositórios não precisem pesquisar um arquivo simples para garantir que ele não esteja adicionando entradas duplicadas.
- Ele permite que um administrador de sistema desabilite (renomeando) ou remova (excluindo) facilmente um conjunto de repositórios sem precisar editar um arquivo monolítico.
- Ele permite que um mantenedor de pacote forneça um comando simples para atualizar os locais dos repositórios sem ter que se preocupar em alterar inadvertidamente a configuração de repositórios não relacionados.
Responder2
No nível técnico, como alguém que teve que lidar com essas mudanças em algumas ferramentas grandes e populares de informações do sistema, basicamente tudo se resume a isto:
Para fontes.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
Observe que, a menos que eles também estejam fazendo a mesma verificação abaixo, se você tivesse comentado uma linha do repositório, esses testes estariam errados. Se eles estiverem fazendo a mesma verificação abaixo, então é exatamente a mesma complexidade, exceto que é realizada em muitos arquivos, não em um. Além disso, a menos que estejam verificando TODOS os arquivos possíveis, eles podem, e muitas vezes o fazem, adicionar um item duplicado, o que faz com que você reclame, até que você exclua um deles.
Para fontes.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
Os desenvolvedores do Google Chrome não verificaram a presença de fontes do Google Chrome, contando com o nome exato do arquivo que seu pacote do Chrome criaria para estar presente. Em todos os outros casos, eles criariam um novo arquivo em sources.list.d com o nome exatamente como desejavam.
Para ver quais fontes você tem, é claro, não é tão bonito, já que não há nada mais fácil de ler e manter do que:
cat /etc/sources.list
Então, isso foi feito basicamente com o propósito de atualizações automatizadas e para fornecer comandos únicos e fáceis que você poderia fornecer aos usuários, até onde eu sei. Para os usuários, isso significa que eles precisam ler muitos arquivos em vez de um arquivo para ver se têm um repositório adicionado e, para o apt, significa que ele também precisa ler muitos arquivos em vez de um arquivo.
Já que no mundo real, se você quiser fazer isso bem, terá que suportar verificações em todos os arquivos, independentemente do nome deles, e então testar se a ação a ser executada é necessária ou não.
No entanto, se você não fizer isso bem, basta ignorar as verificações para ver se o item está em algum lugar nas fontes e apenas verificar o nome do arquivo. Acredito que é isso que a maioria das coisas automatizadas faz, mas como no final, eu simplesmente tive que verificar tudo para poder listá-lo e agir com base na correspondência de um desses arquivos, o único resultado real foi tornar tudo muito mais complicado.
Edições em massa
Considerando a execução de muitos servidores, eu ficaria tentado a apenas criar um script de trabalho noturno que percorre /etc/apt/sources.list.d/ e verifica primeiro para ter certeza de que o item já não está em sources.list, então se estiver não, adicione esse item a fontes.list, exclua o arquivo fontes.list.d e, se já estiver em fontes.list, apenas exclua o arquivo fontes.list.d
Como NÃO há nenhum aspecto negativo em usar apenas o sources.list além da simplicidade e facilidade de manutenção, adicionar algo assim pode não ser uma má ideia, especialmente dadas as ações aleatórias criativas dos administradores de sistema.
Conforme observado no comentário acima, inxi -r imprimirá ordenadamente por arquivo os repositórios ativos, mas é claro que não os editará ou alterará, então isso seria apenas metade da solução. Se houver muitas distribuições, será difícil aprender como cada uma faz isso, isso é certo, e a aleatoriedade certamente é a regra e não a exceção, infelizmente.
Responder3
Se você gerencia manualmente seus servidores, concordo que isso torna as coisas mais confusas. No entanto, beneficia o gerenciamento programático (ou seja, "configuração como código"). Ao usar software de gerenciamento de configuração como Puppet, Ansible, Chef, etc., é mais fácil simplesmente soltar ou remover um arquivo em um diretório e executar apt update, em vez de analisar um arquivo para adicionar ou remover determinadas linhas.
Especialmente porque isso evita ter que gerenciar o conteúdo de um único recurso de 'arquivo', por exemplo: /etc/apt/sources.list, de vários módulos independentes que foram escritos por terceiros.
Agradeço o amplo uso de diretórios ".d" pelo Ubuntu por esse motivo específico, ou seja, sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d, etc.
Responder4
Isso permite que os pacotes adicionem fontes extras sem recorrer a scripts.
Por exemplo, quando você instala o pacote Skype da Microsoft, uma fonte para skype.com é automaticamente configurada para baixar atualizações; remover o pacote Skype do sistema também desabilita esta fonte de pacote novamente.
Se você quisesse ter o mesmo efeito com um arquivo simples, os scripts de instalação do Skype precisariam modificar seu sources.list, o que provavelmente muitos administradores de sistema achariam um pouco enervante.