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

Ter cada repositório (ou coleção de repositórios) em seu próprio arquivo simplifica 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 não estejam adicionando entradas duplicadas.
• Ele permite que um administrador de 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 forneça um comando simples para atualizar os locais do repositório sem ter que se preocupar em alterar inadvertidamente a configuração de repositórios não relacionados.

Em um nível técnico, como alguém que teve que lidar com essas mudanças em algumas grandes e populares ferramentas 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ê tivesse comentado uma linha de repositório, esses testes estariam errados. Se eles estiverem fazendo a mesma verificação abaixo, é exatamente a mesma complexidade, exceto que é realizada em muitos arquivos, não em um. Além disso, a menos que eles estejam verificando TODOS os arquivos possíveis, eles podem, e geralmente o fazem, adicionar um item duplicado, o que faz com que ele reclame, até que você exclua um deles.

Para fontes.lista

# 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 de arquivo exato que seu pacote do Chrome criaria para estar presente. Em todos os outros casos, eles criariam um novo arquivo em sources.list.d nomeado exatamente da maneira que desejassem.

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

cat /etc/sources.list

Portanto, isso foi feito basicamente com o objetivo de atualizações automatizadas e para fornecer comandos únicos 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 1 arquivo para ver se eles têm um repositório adicionado e, para o apt, significa que ele deve ler muitos arquivos em vez de um arquivo também.

Já que no mundo real, se você vai fazer isso bem, você deve 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. Eu acredito que é o que a maioria das coisas automatizadas fazem, 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 torná-lo muito mais complicado.

edições em massa

Dado 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 garantir que o item já não esteja em sources.list, então se estiver não, adicione esse item a sources.list, exclua o arquivo sources.list.d e, se já estiver em sources.list, apenas exclua o arquivo sources.list.d

Uma vez que NÃO há NENHUMA desvantagem em usar apenas sources.list além da simplicidade e facilidade de manutenção, adicionar algo assim pode não ser uma má ideia, especialmente devido às ações aleatórias criativas dos administradores do sistema.

Conforme observado no comentário acima, inxi -r imprimirá ordenadamente por arquivo os repositórios ativos, mas obviamente não os editará ou alterará, de modo que seria apenas metade da solução. Se são 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.

Se você estiver gerenciando 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 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.

Eu aprecio 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.

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 ideia de pacotes - partes independentes de software que podem, tanto quanto possível, ser adicionadas e removidas atomicamente. Sempre que você instala um pacote com dpkg(e, portanto apt, ), ele rastreia quais arquivos no sistema foram criados por aquele instalador. A desinstalação do pacote pode consistir basicamente na exclusão desses arquivos.

A resposta atualmente aceita considera uma coisa ruim que um instalador do Google Chrome presumiu que deveria 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 próximos a ela, o arquivo ficará com comentários corrompidos.
• 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 propriedade; por exemplo, o instalador pode incluir um bloco de comentários afirmando que é "proprietário" de um determinado conjunto de linhas. Nesse caso, ele sempre procuraria no arquivo aquele bloco exato, não alguma outra menção ao mesmo repositório.

Tudo o mais sendo 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, a remoção de linhas requer o uso de alguma ferramenta de correspondência de padrões, como sed. Em um arquivo mais complexo, adicionar e remover 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 ao redor.

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

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 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 achariam um pouco enervante.

Não estou convencido de que haja uma boa razão - além de parecer moda. Para mim, isso quebra uma regra de que um diretório deve ser uma folha ou uma ramificação - ou seja, que deve conter apenas arquivos ou diretórios, não uma mistura de ambos.

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

Aí eu me contradisse.

Acho que não fui claro.

Na minha opinião, deveria haver um diretório /etc/.../list.d, mas todos os arquivos deveriam estar lá. É feio e mais difícil de analisar quando parte da configuração está em um diretório separado. Arquivos separados para cada repositório, mas todos em um único diretório ou todos em subdiretórios, portanto

/etc/
/etc/${sistema}
/etc/${sistema}/common
/etc/${sistema}/use_1
/etc/${sistema}/use_2

e assim por diante.

Isso permite que a propriedade (como outros mencionaram) seja refinada. o diretório /etc/${system} (onde o sistema pode ser yum/apt, ou qualquer outro) seria propriedade do root, grupo o que o sistema espera, com rw para grupo e --- para outro. os diretórios use_{1,2} podem pertencer a usuários mais apropriados.

Como Seamus comentou, o que funcionar para você é o melhor.