Le fait d'avoir chaque référentiel (ou ensemble de référentiels) dans son propre fichier simplifie la gestion, à la fois manuellement et par programmation :
- Cela permet aux nouvelles installations qui ont besoin de leurs propres référentiels 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 facilement désactiver (en renommant) ou supprimer (en supprimant) un ensemble de référentiels sans avoir à modifier un fichier monolithique.
- Cela permet à un mainteneur de paquet de donner une simple commande 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.
D'un point de vue 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 essentiellement à 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 effectuent la même vérification que ci-dessous, c'est exactement la même complexité, sauf qu'elle est effectuée sur de nombreux fichiers, pas un seul. 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 peut alors se plaindre jusqu'à ce que vous supprimiez l'un d'entre eux.
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 de Google Chrome n'ont pas vérifié la présence de sources Google Chrome, se basant 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, puisque vous ne pouvez pas être plus facile à lire et à maintenir que :
cat /etc/sources.list
Donc, cela a été essentiellement fait à des fins de mises à jour automatisées et pour fournir des commandes uniques simples que vous pourriez donner aux utilisateurs, pour autant que je sache. Pour les utilisateurs, cela signifie qu'ils doivent lire plusieurs fichiers au lieu d'un seul fichier pour voir s'ils ont ajouté un référentiel, et pour apt, cela signifie qu'il doit également lire plusieurs fichiers au lieu d'un seul.
Puisque dans le monde réel, si vous alliez bien faire cela, 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 ne le faisiez pas bien, vous ignoreriez simplement les vérifications pour voir si l'élément se trouve quelque part dans les sources et vérifieriez simplement le nom du fichier. Je crois que c'est ce que font la plupart des choses automatisées, mais comme à la fin, je devais simplement tout vérifier pour pouvoir le lister et agir en fonction de la correspondance de l'un de ces fichiers, le seul résultat réel était de le rendre beaucoup plus compliqué.
Modifications groupées
Compte tenu de l'exécution de nombreux serveurs, je serais tenté de simplement scripter un travail nocturne qui parcourt /etc/apt/sources.list.d/ et vérifie d'abord pour s'assurer que l'élément n'est pas déjà dans sources.list, alors si c'est le cas 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 à utiliser uniquement sources.list au-delà de la simplicité et de la facilité de maintenance, ajouter quelque chose comme ça n'est peut-être pas une mauvaise idée, en particulier compte tenu des actions aléatoires créatives des administrateurs système.
Comme indiqué dans le commentaire ci-dessus, inxi -r imprimera proprement par fichier les dépôts actifs, mais ne les modifiera bien sûr pas, ce ne serait donc que la moitié de la solution. S'il y a plusieurs distributions, il est difficile d'apprendre comment chacune le fait, c'est sûr, et le hasard est certainement la règle plutôt que l'exception, malheureusement.
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 la "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 d'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', ex :/etc/apt/sources.list , à partir de plusieurs modules indépendants qui ont été écrits par des tiers.
J'apprécie l'utilisation généralisée par Ubuntu des répertoires ".d" pour cette raison particulière, c'est-à-dire sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d, etc.