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

Question

Eu sei que esta pergunta foi feita antes, mas eu não aceito a resposta, "você pode ver claramente adições personalizadas". Quando eu adiciono o ppa (que eu não faço há anos), eu bati uma tecla no meu teclado rotulado "Enter", que me permite adicionar uma linha vazia antes da nova entrada (eu ainda adicionaria um comentário explicativo, mas eu sou um escritor técnico, então ....). Eu gosto do meu sources.conf clean and clean.

/etc/apt/sources.d

Significa que eu 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 mesmo 2, não importa ... 1 ainda é melhor que 2).

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

Devo acrescentar que adoro mudar, no entanto, SOMENTE quando houver benefícios introduzidos pela mudança.

Editar após a primeira resposta:

It allows new installations that need their own repos to not have to search a flat file to ensure that it is not adding duplicate entries.

Agora, eles precisam procurar um diretório por dupe em vez de um arquivo simples. A menos que eles achem que o admin não muda as coisas ...

It allows a system administrator to easily disable (by renaming) or remove (by deleting) a repository set without having to edit a monolithic file.

O administrador tem que usar o diretório para encontrar o arquivo apropriado para renomear, antes, ele procuraria por um arquivo e comentaria uma linha, uma frase simples para "quase" qualquer administrador.

It allows a package maintainer to give a simple command to update repository locations without having to worry about inadvertently changing the configuration for unrelated repositories.

Eu não entendo este, eu "presumo" que o mantenedor do pacote conhece a URL do seu repositório. Novamente, tem que sed um diretório em vez de um único arquivo.

    

Answer 1

Em um nível técnico, como alguém que teve que lidar com essas alterações em algumas ferramentas de informações de sistema grandes e populares, 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

Note que, a menos que eles também estejam fazendo a mesma verificação abaixo, se você comentou uma linha de recompra, esses testes estariam errados. Se eles estão fazendo a mesma verificação como abaixo, então é a mesma complexidade exata, exceto realizada em muitos arquivos, não em um. Além disso, a menos que estejam verificando TODOS os arquivos possíveis, eles podem, e freqüentemente adicionam, um item duplicado, que então faz com que 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 que o pacote do Chrome criaria para estar presente. Em todos os outros casos, eles criariam um novo arquivo em sources.list.d chamado exatamente da maneira que desejavam.

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

Então, isso foi basicamente feito com o propósito de atualizações automáticas e para fornecer comandos simples e fáceis que você poderia dar aos usuários, até onde eu saiba. Para os usuários, isso significa que eles têm que ler muitos arquivos em vez de um arquivo para ver se eles têm um repo adicionado, e para o apt, isso significa que ele tem que ler muitos arquivos em vez de um arquivo também.

Como no mundo real, se você fosse fazer isso bem, você teria que dar 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 necessária. .

No entanto, se você não fosse fazê-lo bem, você simplesmente ignoraria as verificações para ver se o item está em algum lugar nas origens e apenas verificar o nome do arquivo. Eu acredito que é o que a maioria das coisas automatizadas faz, mas como no final, eu simplesmente tinha que checar tudo para que eu pudesse listar e agir baseado em um desses arquivos, o único resultado real era torná-lo muito mais complicado. / p>

Edições em massa

Tendo em conta a execução de muitos servidores, eu ficaria tentado a apenas escrever um trabalho noturno que faça um loop através do /etc/apt/sources.list.d/ e verifique primeiro se o item não está no sources.list já, então se não estiver, 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

Como NÃO há nenhum negativo em usar apenas sources.list além da simplicidade e da facilidade de manutenção, adicionar algo assim pode não ser uma má ideia, especialmente dadas ações aleatórias criativas pelos administradores do sistema.

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

    

Answer 2

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

• 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.
• Permite que um administrador do sistema desative (renomeando) ou remover (excluindo) um conjunto de repositórios sem precisar editar um arquivo monolítico.
• Permite que um mantenedor de pacotes forneça um comando para atualizar os locais do repositório sem ter que se preocupar alterando inadvertidamente a configuração de repositórios não relacionados.

Answer 3

Se você estiver gerenciando manualmente seus servidores, concordarei que isso torna as coisas mais confusas. No entanto, beneficia o gerenciamento programático (por exemplo, "configuração como código"). Ao usar softwares de gerenciamento de configuração como Puppet, Ansible, Chef, etc., é mais fácil simplesmente descartar ou remover um arquivo em um diretório e executar apt update , em vez de analisar um arquivo para adicionar ou remover certas 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.

Eu aprecio o amplo uso do Ubuntu de diretórios ".d" para esse motivo em particular, ou seja, sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d, etc.

    

Answer 4

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

As distribuições e instaladores Linux modernos são todos baseados na idéia 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 controla quais arquivos no sistema foram criados por esse instalador. A desinstalação do pacote pode consistir, em grande parte, na exclusão desses arquivos.

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

• Se a linha existe em sources.list ao instalar, mas está comentado, o instalador deve remover o comentário ou adicionar uma duplicata?
• Se o desinstalador remover a linha, mas o usuário tiver adicionado ou editado comentários ao lado dela, o arquivo ficará com comentários corrompidos.
• Se o usuário adicionasse manualmente a linha, o instalador poderia saber não 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 "possui" um determinado conjunto de linhas. Nesse caso, ele sempre procuraria o arquivo por esse bloco exato, não por alguma outra menção ao mesmo repositório.

Sendo o restante igual, automatizar as edições em um único arquivo de configuração sempre será mais complicado do que automatizar a criação e a 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, a adição e a remoção de linhas podem exigir uma ferramenta de script com conhecimento do formato do arquivo, para incluir em uma seção apropriada ou remover sem danificar a formatação ao redor.

Como um instalador precisaria evitar mexer na 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 de ser gerenciado por ferramentas automatizadas.

    

Answer 5

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; remover o pacote Skype do sistema também desativa essa fonte de pacotes novamente.

Se você quisesse ter o mesmo efeito com um arquivo simples, os scripts de instalação do Skype precisariam modificar o seu sources.list, o que, provavelmente, muitos administradores do sistema considerariam um pouco irritante.

    

Answer 6

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

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

Lá, eu me contradizei.