Qual é o benefício de /etc/apt/sources.list.d sobre /etc/apt/sources.list

Sei que essa pergunta já foi feita antes, mas não aceito a resposta "você pode ver claramente adições personalizadas". Quando adiciono ppa's (o que não faço há anos), pressionei uma tecla do teclado chamada "Enter", que permite adicionar uma linha vazia antes da nova entrada (eu acrescentaria um comentário explicativo, mas sou um escritor 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" nenhuma vantagem em ter um arquivo de configuração vs 6 (por uma questão de argumento, talvez você tenha 3 ou até 2, não importa ... 1 ainda bate 2).

Alguém pode, por favor, apresentar uma vantagem racional: "você pode ver claramente adições personalizadas" é a desculpa de um pobre homem.

Devo acrescentar, eu amo a mudança, no entanto, SOMENTE quando houver benefícios introduzidos pela mudança.

Edite após a primeira resposta:

Ele permite que novas instalações que precisam de seus próprios repositórios não precisem procurar um arquivo simples para garantir que ele não esteja adicionando entradas duplicadas.

Agora, eles precisam procurar em um diretório por arquivos duplicados, em vez de simples. A menos que eles assumam que os administradores não mudam as coisas ...

Ele permite que um administrador do sistema desative facilmente (renomeando) ou remova (excluindo) um conjunto de repositórios sem precisar editar um arquivo monolítico.

Admin tem que grep diretório para encontrar o arquivo apropriado para renomear, antes, ele iria procurar um arquivo e comentar uma linha, uma linha de sed para "quase" qualquer administrador.

Ele permite que um mantenedor de pacote dê um comando simples para atualizar os locais do repositório sem precisar se preocupar em alterar inadvertidamente a configuração de repositórios não relacionados.

Eu não entendo esse, eu "suponho" que o mantenedor do pacote saiba a URL do seu repositório. Novamente, tem sedum diretório em vez de um único arquivo.

Em nível técnico, como alguém que teve que lidar com essas alterações em algumas ferramentas grandes e populares de informações do sistema, basicamente se resume a isso:

Para 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

Observe que, a menos que eles também estejam fazendo a mesma verificação abaixo, se você tiver comentado uma linha de recompra, esses testes estarão errados. Se eles estiverem fazendo a mesma verificação abaixo, é a mesma complexidade exata, exceto executada em muitos arquivos, não em um. Além disso, a menos que eles estejam verificando TODOS os arquivos possíveis, eles podem, e costumam adicionar, um item duplicado, o que faz o apt reclamar, até que você exclua um deles.

Para 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

Os desenvolvedores do Google Chrome não verificaram a presença de fontes do Google Chrome, contando com o nome exato do arquivo que o pacote Chrome criaria para estar presente. Em todos os outros casos, eles criariam um novo arquivo no sources.list.d nomeado exatamente do jeito que eles queriam.

Para ver quais fontes você tem, é claro, não é tão bonito, pois você não pode ficar mais fácil de ler e manter do que:

cat /etc/sources.list

Portanto, isso foi basicamente feito com o objetivo de atualizações automatizadas e para fornecer comandos simples e simples 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 eles foram adicionados a um repositório e, para o apt, isso significa que ele também precisa ler muitos arquivos em vez de um arquivo.

Como no mundo real, se você deseja fazer isso bem, é necessário oferecer suporte a verificações em todos os arquivos, independentemente do nome, e depois testar se a ação a ser executada é necessária ou não.

No entanto, se você não for bem-sucedido, 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, simplesmente tive que verificar tudo para poder listá-las e agir com base em se um desses arquivos correspondia, o único resultado real era torná-lo muito mais complicado.

Edições em massa

Dada a execução de muitos servidores, eu ficaria tentado a criar um trabalho noturno que percorra o arquivo /etc/apt/sources.list.d/ e verifique primeiro se o item já não está no sources.list e, em seguida, se for não, adicione esse item ao sources.list, exclua o arquivo sources.list.d e, se já estiver no sources.list, apenas exclua o arquivo sources.list.d

Como NÃO há nada negativo em usar apenas o sources.list além da simplicidade e da facilidade de manutenção, adicionar algo assim pode não ser uma má idéia, principalmente devido às ações aleatórias criativas dos administradores de sistemas.

Conforme observado no comentário acima, o inxi -r imprimirá ordenadamente por arquivo os repositórios ativos, mas não os editará ou os alterará, é claro que seria apenas metade da solução. Se há muitas distribuições, é difícil aprender como cada uma faz isso, com certeza, e a aleatoriedade certamente é a regra, e não a exceção, infelizmente.

Ter cada repositório (ou coleção de repositórios) em seu próprio arquivo facilita o gerenciamento, tanto manualmente quanto programaticamente:

• Ele permite que novas instalações que precisam de seus próprios repositórios não precisem procurar um arquivo simples para garantir que ele não esteja adicionando entradas duplicadas.
• Ele permite que um administrador do sistema desative facilmente (renomeando) ou remova (excluindo) um conjunto de repositórios sem precisar editar um arquivo monolítico.
• Ele permite que um mantenedor de pacote dê um comando simples para atualizar os locais do repositório sem precisar se preocupar em alterar inadvertidamente a configuração de repositórios não relacionados.

Se você estiver gerenciando manualmente seus servidores, eu concordo que isso torna as coisas mais confusas. No entanto, beneficia o gerenciamento programático (ou seja, "configuração como código"). Ao usar um software de gerenciamento de configuração como Puppet, Ansible, Chef, etc., é mais fácil 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 a necessidade de gerenciar o conteúdo de um único recurso 'arquivo', por exemplo: /etc/apt/sources.listde vários módulos independentes que foram gravados por terceiros.

Eu aprecio o amplo uso do Ubuntu de diretórios ".d" por esse motivo específico, por exemplo, sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, etc.

Como nemo apontou em um comentário, uma das principais vantagens de um diretório é permitir a noção de "propriedade".

As distribuições e instaladores modernos do Linux são todos baseados na idéia de pacotes - software independente que pode, na medida do possível, ser adicionado e removido atomicamente. Sempre que você instala um pacote com dpkg(e, portanto apt), ele controla quais arquivos no sistema foram criados por esse instalador. A desinstalação do pacote pode consistir principalmente na exclusão desses arquivos.

A resposta atualmente aceita considera ruim o fato de um instalador do Google Chrome presumir que ele deve apenas criar ou excluir uma entrada no local esperado, mas automatizar qualquer outra coisa leva a todos os tipos de casos extremos horríveis; por exemplo:

• Se a linha existir sources.listdurante a instalação, mas estiver comentada, o instalador deve descomentá-la ou adicionar uma duplicata?
• Se o desinstalador remover a linha, mas o usuário tiver adicionado ou editado comentários ao lado, o arquivo ficará com comentários quebrados.
• Se o usuário adicionou manualmente a linha, o instalador pode saber que não deve adicioná-la; mas como o desinstalador saberia não removê-lo?

Arquivos separados não são necessários para a propriedade; por exemplo, o instalador pode incluir um bloco de comentários afirmando que "possui" um conjunto específico de linhas. Nesse caso, ele sempre procuraria no arquivo pelo bloco exato, não por outra menção ao mesmo repositório.

Tudo o resto é igual, automatizar edições em um único arquivo de configuração sempre será mais complicado do que automatizar a criação e exclusão de um arquivo separado. No mínimo, remover linhas requer o uso de alguma ferramenta de correspondência de padrões, como sed. Em um arquivo mais complexo, a adição e remoção de linhas pode exigir uma ferramenta de script com conhecimento do formato do arquivo, para adicionar a uma seção apropriada ou remover sem danificar a formatação circundante.

Como um instalador precisaria evitar mexer com a configuração editada manualmente de qualquer maneira, faz sentido colocar a configuração automatizada e de propriedade de uma ferramenta em um formato fácil para o gerenciamento de ferramentas automatizadas.

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 é configurada automaticamente para baixar atualizações; a remoção do pacote do Skype do sistema também desativa essa 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 considerariam um pouco irritante.

Não estou convencido de que exista um bom motivo - além do que parece estar na moda. Para mim, ele quebra uma regra de que um diretório deve ser uma folha ou um nó - ou seja, que ele deve conter apenas arquivos ou diretórios, não uma mistura de ambos.

Suponho que ele torna os arquivos menores e mais fáceis de ler - no caso de regras sudo, que podem ser bastante longas, facilita o conjunto de regras padronizadas para um tipo de usuário (por exemplo, um desenvolvedor ) e adicione-os ao diretório de configuração se os devs puderem sudo nesta máquina; portanto, você precisa manter menos arquivos - apenas um arquivo para desenvolvedores, administradores, sysops etc., em vez de para todas as combinações possíveis.

Lá, eu me contradiz.