Ich weiß, dass diese Frage schon einmal gestellt wurde, aber ich akzeptiere die Antwort „Sie können benutzerdefinierte Ergänzungen deutlich sehen“ nicht. Wenn ich PPAs hinzufüge (was ich seit Jahren nicht mehr getan habe), drücke ich auf meiner Tastatur eine Taste mit der Bezeichnung „Enter“, mit der ich vor dem neuen Eintrag eine leere Zeile einfügen kann (ich würde sogar einen erklärenden Kommentar hinzufügen, aber ich bin ein technischer Redakteur, also …). Ich mag es sources.confsauber und ordentlich.
/etc/apt/sources.d
Das bedeutet, dass ich ein halbes Dutzend Dateien analysieren muss statt nur einer.
Soweit ich weiß, gibt es „absolut“ keinen Vorteil, wenn man eine Konfigurationsdatei gegenüber sechs hat (der Argumentation halber: vielleicht haben Sie 3 oder sogar 2, das spielt keine Rolle … 1 ist immer noch besser als 2).
Kann mir bitte jemand einen rationalen Vorteil nennen? „Man sieht deutlich die Sonderanfertigungen“ ist eine Ausrede für schwache Leute.
Ich muss hinzufügen, dass ich Veränderungen liebe, allerdings NUR, wenn sie auch Vorteile mit sich bringen.
Nach der ersten Antwort bearbeiten:
Dadurch müssen neue Installationen, die ihre eigenen Repos benötigen, nicht in einer Flatfile suchen, um sicherzustellen, dass keine doppelten Einträge hinzugefügt werden.
Jetzt müssen sie in einem Verzeichnis nach Duplikaten suchen, statt in einer einfachen Datei. Es sei denn, sie gehen davon aus, dass Administratoren nichts ändern ...
Es ermöglicht einem Systemadministrator, ein Repository-Set einfach zu deaktivieren (durch Umbenennen) oder zu entfernen (durch Löschen), ohne eine monolithische Datei bearbeiten zu müssen.
Der Administrator muss das Verzeichnis durchsuchen, um die entsprechende Datei zum Umbenennen zu finden. Zuvor musste er EINE Datei durchsuchen und eine Zeile auskommentieren, ein Sed-Einzeiler für „fast“ jeden Administrator.
Es ermöglicht einem Paketbetreuer, einen einfachen Befehl zum Aktualisieren von Repository-Speicherorten einzugeben, ohne befürchten zu müssen, versehentlich die Konfiguration für nicht verwandte Repositorys zu ändern.
Das verstehe ich nicht, ich „nehme an“, dass der Paketbetreuer die URL seines Repositorys kennt. Auch hier muss es sich um sedein Verzeichnis handeln, nicht um eine einzelne Datei.
Antwort1
Wenn jedes Repository (oder jede Repository-Sammlung) in einer eigenen Datei vorliegt, ist die Verwaltung sowohl manuell als auch programmgesteuert einfacher:
- Dadurch müssen neue Installationen, die ihre eigenen Repos benötigen, nicht in einer Flatfile suchen, um sicherzustellen, dass keine doppelten Einträge hinzugefügt werden.
- Es ermöglicht einem Systemadministrator, ein Repository-Set einfach zu deaktivieren (durch Umbenennen) oder zu entfernen (durch Löschen), ohne eine monolithische Datei bearbeiten zu müssen.
- Es ermöglicht einem Paketbetreuer, einen einfachen Befehl zum Aktualisieren von Repository-Speicherorten einzugeben, ohne befürchten zu müssen, versehentlich die Konfiguration für nicht verwandte Repositorys zu ändern.
Antwort2
Auf technischer Ebene läuft es für mich als jemanden, der diese Änderungen in einigen großen und beliebten Systeminfo-Tools handhaben musste, im Wesentlichen auf Folgendes hinaus:
Für 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
Beachten Sie, dass diese Tests falsch wären, wenn Sie eine Zeile im Repo auskommentiert hätten, es sei denn, sie führen auch die gleiche Prüfung wie unten durch. Wenn sie die gleiche Prüfung wie unten durchführen, ist die Komplexität genau gleich, nur dass sie über viele Dateien und nicht über eine ausgeführt wird. Wenn sie nicht ALLE möglichen Dateien prüfen, können sie außerdem ein doppeltes Element hinzufügen (und tun dies auch oft), was apt dann beschwert, bis Sie eines davon löschen.
Für 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
Die Google Chrome-Entwickler haben nicht nach Google Chrome-Quellen gesucht, sondern sich auf den genauen Dateinamen verlassen, den ihr Chrome-Paket erstellen würde. In allen anderen Fällen haben sie eine neue Datei in sources.list.d erstellt, die genau den gewünschten Namen hatte.
Um zu sehen, welche Quellen Sie haben, ist es natürlich nicht so schön, denn einfacher zu lesen und zu pflegen geht es nicht:
cat /etc/sources.list
Dies wurde also, soweit ich das beurteilen kann, im Wesentlichen zum Zweck automatischer Updates und zur Bereitstellung einfacher Einzelbefehle gemacht, die man den Benutzern geben kann. Für Benutzer bedeutet dies, dass sie viele Dateien statt nur einer Datei lesen müssen, um zu sehen, ob sie ein Repo hinzugefügt haben, und für apt bedeutet dies, dass es ebenfalls viele Dateien statt nur einer Datei lesen muss.
Denn wenn Sie dies in der Praxis gut umsetzen möchten, müssen Sie Prüfungen aller Dateien durchführen, unabhängig von ihren Namen, und dann testen, ob die auszuführende Aktion erforderlich ist oder nicht.
Wenn Sie es jedoch nicht richtig machen würden, würden Sie die Überprüfungen, ob das Element irgendwo in den Quellen vorhanden ist, einfach ignorieren und nur nach dem Dateinamen suchen. Ich glaube, das ist es, was die meisten automatisierten Dinge tun, aber da ich am Ende einfach alles überprüfen musste, damit ich es auflisten und basierend darauf handeln konnte, ob eine dieser Dateien übereinstimmte, war das einzige wirkliche Ergebnis, dass es viel komplizierter wurde.
Massenbearbeitungen
Da ich viele Server betreibe, wäre ich versucht, einfach einen nächtlichen Job zu skripten, der /etc/apt/sources.list.d/ durchläuft und zuerst überprüft, ob das Element nicht bereits in sources.list vorhanden ist. Wenn dies nicht der Fall ist, füge ich das Element dann zu sources.list hinzu, lösche die Datei sources.list.d und lösche, wenn es bereits in sources.list vorhanden ist, einfach die Datei sources.list.d.
Da es außer der Einfachheit und Wartungsfreundlichkeit KEINE Nachteile hat, nur sources.list zu verwenden, wäre das Hinzufügen einer solchen Option möglicherweise keine schlechte Idee, insbesondere angesichts der kreativen Zufallsaktionen von Systemadministratoren.
Wie im obigen Kommentar erwähnt, druckt inxi -r die aktiven Repos ordentlich pro Datei aus, bearbeitet oder ändert sie aber natürlich nicht, sodass dies nur die halbe Lösung wäre. Wenn es sich um viele Distributionen handelt, ist es sicherlich mühsam zu lernen, wie jede es macht, das ist sicher, und Zufälligkeit ist leider sicherlich eher die Regel als die Ausnahme.
Antwort3
Wenn Sie Ihre Server manuell verwalten, stimme ich zu, dass es die Dinge verwirrender macht. Es kommt jedoch der programmgesteuerten Verwaltung zugute (d. h. „Konfiguration als Code“). Wenn Sie Konfigurationsverwaltungssoftware wie Puppet, Ansible, Chef usw. verwenden, ist es einfacher, eine Datei einfach in einem Verzeichnis abzulegen oder zu entfernen und auszuführen apt update, anstatt eine Datei zu analysieren, um bestimmte Zeilen hinzuzufügen oder zu entfernen.
Dies vermeidet insbesondere, da dadurch die Verwaltung des Inhalts einer einzelnen „Datei“-Ressource, z. B.: /etc/apt/sources.list, aus mehreren unabhängigen Modulen, die von Dritten geschrieben wurden, vermieden wird.
Aus diesem Grund schätze ich Ubuntus umfassende Verwendung von „.d“-Verzeichnissen, z. B. sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d usw.
Antwort4
Dadurch können Pakete zusätzliche Quellen hinzufügen, ohne auf Skripte zurückgreifen zu müssen.
So wird etwa bei der Installation des Skype-Pakets von Microsoft automatisch eine Quelle für skype.com zum Download von Updates konfiguriert; das Entfernen des Skype-Pakets vom System deaktiviert auch diese Paketquelle wieder.
Wenn Sie denselben Effekt mit einer Flachdatei erzielen möchten, müssten die Installationsskripte für Skype Ihre sources.list ändern, was viele Systemadministratoren wahrscheinlich etwas beunruhigend finden würden.