Quel est l'avantage de /etc/apt/sources.list.d sur /etc/apt/sources.list

Je sais que cette question a déjà été posée, mais je n'accepte pas la réponse "vous pouvez clairement voir les ajouts personnalisés". Lorsque j'ajoute des ppa (ce que je n'ai pas fait depuis des années), je tape une touche sur mon clavier intitulée "Entrée" qui me permet d'ajouter une ligne vide avant la nouvelle entrée (j'ajouterais même un commentaire explicatif, mais je suis un rédacteur technique, donc ....). J'aime mon sources.confpropre et soigné.

/etc/apt/sources.d

Cela signifie que j'ai une demi-douzaine de fichiers à analyser au lieu d'un seul.

AFAIK, il n'y a "absolument" aucun avantage à avoir un fichier de configuration vs 6 (pour des raisons d'argument, peut-être que vous en avez 3 ou même 2, peu importe ... 1 bat toujours 2).

Quelqu'un peut-il s'il vous plaît trouver un avantage rationnel, "vous pouvez clairement voir les ajouts personnalisés" est une excuse du pauvre.

Je dois ajouter, j'aime le changement, cependant, UNIQUEMENT lorsqu'il y a des avantages introduits par le changement.

Modifier après la première réponse:

Il permet aux nouvelles installations qui ont besoin de leur propre référentiel de ne pas avoir à rechercher un fichier plat pour s'assurer qu'il n'ajoute pas d'entrées en double.

Maintenant, ils doivent rechercher un dupe au lieu d'un fichier plat. À moins qu'ils ne supposent que les administrateurs ne changent rien ...

Il permet à un administrateur système de désactiver facilement (en renommant) ou de supprimer (en supprimant) un ensemble de référentiels sans avoir à modifier un fichier monolithique.

L'administrateur doit grep répertoire pour trouver le fichier approprié à renommer, avant, il recherchait UN fichier et commenter une ligne, un one-liner sed pour "presque" n'importe quel administrateur.

Il permet à un mainteneur de package de donner une commande simple pour mettre à jour les emplacements des référentiels sans avoir à se soucier de modifier par inadvertance la configuration des référentiels non liés.

Je ne comprends pas celui-ci, je "suppose" que le responsable du paquet connaît l'URL de son référentiel. Encore une fois, a sedun répertoire au lieu d'un seul fichier.

Sur le plan technique, en tant que personne qui a dû gérer ces changements dans quelques grands outils d'informations système populaires, cela se résume à ceci:

Pour 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

Notez qu'à moins qu'ils ne fassent également la même vérification que ci-dessous, si vous aviez commenté une ligne de dépôt, ces tests seraient erronés. S'ils font la même vérification que ci-dessous, alors c'est la même complexité exacte, sauf effectuée sur de nombreux fichiers, pas un. De plus, à moins qu'ils ne vérifient TOUS les fichiers possibles, ils peuvent, et le font souvent, ajouter un élément en double, ce qui fait alors se plaindre apt, jusqu'à ce que vous en supprimiez un.

Pour 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

Les développeurs Google Chrome n'ont pas vérifié la présence de sources Google Chrome, en s'appuyant sur le nom de fichier exact que leur package Chrome créerait pour être présent. Dans tous les autres cas, ils créeraient un nouveau fichier dans sources.list.d nommé exactement comme ils le souhaitaient.

Pour voir quelles sources vous avez, bien sûr, ce n'est pas si joli, car vous ne pouvez pas être plus facile à lire et à maintenir que:

cat /etc/sources.list

Donc, cela a été fait essentiellement dans le but de mises à jour automatisées, et pour fournir des commandes simples faciles que vous pourriez donner aux utilisateurs, pour autant que je sache. Pour les utilisateurs, cela signifie qu'ils doivent lire de nombreux fichiers au lieu d'un seul fichier pour voir s'ils ont un repo ajouté, et pour apt, cela signifie qu'il doit également lire plusieurs fichiers au lieu d'un seul fichier.

Étant donné que dans le monde réel, si vous voulez bien le faire, vous devez prendre en charge les vérifications de tous les fichiers, quel que soit leur nom, puis tester si l'action à effectuer est requise ou non.

Cependant, si vous n'alliez pas le faire correctement, vous ignorez simplement les vérifications pour voir si l'élément se trouve quelque part dans les sources, et vérifiez simplement le nom du fichier. Je pense que c'est ce que font la plupart des choses automatisées, mais comme au final, je devais simplement tout vérifier pour pouvoir le répertorier et agir en fonction de la correspondance de l'un de ces fichiers, le seul vrai résultat était de le rendre beaucoup plus compliqué.

Modifications groupées

Étant donné que plusieurs serveurs sont en cours d'exécution, je serais tenté de simplement écrire un travail nocturne qui passe par /etc/apt/sources.list.d/ et vérifie d'abord que l'élément n'est pas déjà dans sources.list, puis s'il l'est pas, ajoutez cet élément à sources.list, supprimez le fichier sources.list.d et s'il est déjà dans sources.list, supprimez simplement le fichier sources.list.d

Puisqu'il n'y a AUCUN inconvénient à n'utiliser que des sources.list au-delà de la simplicité et de la facilité de maintenance, ajouter quelque chose comme ça pourrait ne pas être une mauvaise idée, en particulier compte tenu des actions créatives aléatoires des administrateurs système.

Comme indiqué dans le commentaire ci-dessus, inxi -r imprimera soigneusement par fichier les dépôts actifs, mais ne les modifiera ni ne les modifiera bien sûr, ce ne serait donc que la moitié de la solution. Si c'est beaucoup de distributions, c'est difficile d'apprendre comment chacune fait, c'est sûr, et le hasard est certainement la règle plutôt que l'exception malheureusement.

Le fait d'avoir chaque référentiel (ou collection de référentiels) dans son propre fichier le rend plus simple à gérer, à la fois manuellement et par programme:

• Il permet aux nouvelles installations qui ont besoin de leur propre référentiel de ne pas avoir à rechercher un fichier plat pour s'assurer qu'il n'ajoute pas d'entrées en double.
• Il permet à un administrateur système de désactiver facilement (en renommant) ou de supprimer (en supprimant) un ensemble de référentiels sans avoir à modifier un fichier monolithique.
• Il permet à un mainteneur de package de donner une commande simple pour mettre à jour les emplacements des référentiels sans avoir à se soucier de modifier par inadvertance la configuration des référentiels non liés.

Si vous gérez manuellement vos serveurs, je conviens que cela rend les choses plus confuses. Cependant, cela profite à la gestion programmatique (c'est-à-dire "configuration en tant que code"). Lorsque vous utilisez un logiciel de gestion de configuration comme Puppet, Ansible, Chef, etc., il est plus facile de simplement déposer ou supprimer un fichier dans un répertoire et de l'exécuter apt update, au lieu d'analyser un fichier pour ajouter ou supprimer certaines lignes.

D'autant plus que cela évite d'avoir à gérer le contenu d'une seule ressource «fichier», par exemple /etc/apt/sources.list:, à partir de plusieurs modules indépendants qui ont été écrits par des tiers.

J'apprécie la large utilisation par Ubuntu des répertoires ".d" pour cette raison particulière, à savoir sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, etc.

Comme l'a souligné Nemo dans un commentaire, l'un des principaux avantages d'un répertoire est qu'il permet la notion de «propriété».

Les distributions et installateurs Linux modernes sont tous basés sur l'idée de packages - des logiciels indépendants qui peuvent, autant que possible, être ajoutés et supprimés de manière atomique. Chaque fois que vous installez un package avec dpkg(et donc apt), il garde la trace des fichiers du système qui ont été créés par ce programme d'installation. La désinstallation du package peut alors consister en grande partie à supprimer ces fichiers.

La réponse actuellement acceptée considère comme une mauvaise chose qu'un programme d'installation de Google Chrome a supposé qu'il ne devrait créer ou supprimer une entrée qu'à l'emplacement attendu, mais l'automatisation de tout le reste conduit à toutes sortes de cas horribles; par exemple:

• Si la ligne existe sources.listlors de l'installation, mais est mise en commentaire, le programme d'installation doit-il la décommenter ou ajouter un doublon?
• Si le programme de désinstallation supprime la ligne, mais que l'utilisateur a ajouté ou modifié des commentaires à côté, le fichier restera avec un commentaire cassé.
• Si l'utilisateur a ajouté manuellement la ligne, le programme d'installation pourrait savoir de ne pas l'ajouter; mais comment le programme de désinstallation saurait-il ne pas le supprimer?

Des fichiers séparés ne sont pas requis pour la propriété; par exemple, l'installateur pourrait inclure un bloc de commentaires indiquant qu'il "possède" un ensemble particulier de lignes. Dans ce cas, il recherchera toujours le fichier pour ce bloc exact, pas pour une autre mention du même référentiel.

Toutes choses étant égales par ailleurs, l'automatisation des modifications dans un seul fichier de configuration sera toujours plus compliquée que l'automatisation de la création et de la suppression d'un fichier distinct. À tout le moins, la suppression de lignes nécessite l'utilisation d'un outil de correspondance de motifs tel que sed. Dans un fichier plus complexe, l'ajout et la suppression de lignes peuvent nécessiter un outil de script connaissant le format de fichier, à ajouter à une section appropriée ou à supprimer sans endommager le formatage environnant.

Dans la mesure où un programme d'installation devrait de toute façon éviter de jouer avec la configuration modifiée manuellement, il est logique de placer la configuration automatisée appartenant à l'outil dans un format facile à gérer pour les outils automatisés.

Cela permet aux packages d'ajouter des sources supplémentaires sans recourir à des scripts.

Par exemple, lorsque vous installez le package Skype de Microsoft, une source pour skype.com est automatiquement configurée pour télécharger les mises à jour; la suppression du package Skype du système désactive également cette source de package.

Si vous vouliez avoir le même effet avec un fichier plat, les scripts d'installation de Skype devraient modifier votre sources.list, ce que beaucoup d'administrateurs système trouveraient probablement un peu énervant.

Je ne suis pas convaincu qu'il y ait une bonne raison - autre que cela semble à la mode. Pour moi, cela enfreint une règle selon laquelle un répertoire doit être une feuille ou un nœud - c'est-à-dire qu'il ne doit contenir que des fichiers ou des répertoires, pas un mélange des deux.

Je suppose que cela rend les fichiers plus petits, donc plus faciles à lire - dans le cas, par exemple, des règles sudo, qui peuvent être assez longues, il est plus facile d'avoir un ensemble normalisé de règles pour un type d'utilisateur (par exemple, un développeur ), et ajoutez-les au répertoire config si les développeurs doivent être autorisés à sudo sur cette machine; vous devez donc gérer moins de fichiers - juste un fichier pour les développeurs, les administrateurs, les sysops, etc., plutôt que pour chaque combinaison possible de ceux-ci.

Là, je me suis contredit.