Doppelte apt-Quellen und deb822-Dateien beheben

Was der Fehler aufgrund doppelter apt-Quellen bedeutet

Doppelte apt-Quellen bedeuten, dass ein Repository zweimal in zwei verschiedenen Dateien eingetragen ist und APT (advanced package tool) beide Einträge gefunden hat. Unter Ubuntu 24.04 und neuer geschieht das fast immer, weil ein Installationsskript eines Drittanbieters eine alte einzeilige .list-Datei geschrieben hat, während bereits eine deb822-.sources-Datei für dasselbe Repository vorhanden war. Es ist nichts beschädigt, und kein Paket ist gefährdet. Löschen Sie einen der beiden Einträge. Danach wird die Meldung nicht mehr angezeigt.

Dies ist die Zeile, die viele in ein Suchfeld einfügen:

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

Lesen Sie die Meldung vom Ende her. Zwei Dateien deklarieren mit jeweils einer Zeilennummer dasselbe. Target Packages ist der Index, den apt herunterlädt, um zu ermitteln, welche Pakete ein Repository anbietet. stable/binary-amd64/Packages bezeichnet die Komponente (stable) und die Architektur (amd64), für die dieser Index gilt. apt teilt Ihnen also mit, dass der amd64-Index für die Komponente stable in docker.list in Zeile 1 konfiguriert ist und erneut in docker.sources in Zeile 1.

In apt 3.0 und neuer, also ab Ubuntu 25.04 und unter Debian 13, beginnt dieselbe Meldung mit Warning: statt mit W:. Der Text nach dem Präfix ist identisch.

Diese Warnung ist der harmlose Fall. apt führt die beiden Einträge zusammen, und das Update läuft weiterhin, weil beide dasselbe Archiv mit demselben Schlüssel beschreiben. Der problematische Fall bricht den Vorgang vollständig ab:

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

apt verweigert den Vorgang hier, weil die beiden Einträge unterschiedliche Signaturschlüssel für ein Archiv angeben. Identische Einträge führt apt zusammen. Zwischen zwei Signed-By-Werten wählt apt jedoch nicht, weil mit der falschen Auswahl die Paketsignaturen gegen einen Schlüssel geprüft würden, mit dem der Betreiber des Archivs nie signiert hat. Deshalb liest apt überhaupt keine Quellen ein. apt update und apt install schlagen beide mit denselben zwei Zeilen fehl, bis Sie die Dateien manuell bearbeiten.

Wie das Duplikat entsteht

Die beiden Formate liegen in separaten Dateien mit unterschiedlichen Endungen. Daher verhindert nichts auf dem Datenträger, dass beide vorhanden sind. apt erkennt die Überschneidung erst spät, wenn es jede Quelldatei in die Liste der Indexziele auflöst, die es abrufen soll. Bis dahin sind docker.list und docker.sources zwei voneinander unabhängige Dateien.

Vier gewöhnliche Vorgänge erzeugen dieses Paar:

• Ein Installationsskript des Anbieters oder ein aus einem älteren Beitrag kopierter Befehl schreibt /etc/apt/sources.list.d/vendor.list mit einer tee-Zeile.
• Das eigene Paket des Anbieters liefert später /etc/apt/sources.list.d/vendor.sources aus und installiert die Datei automatisch.
• add-apt-repository schreibt unter Ubuntu 24.04 und neuer deb822-.sources-Dateien. Dadurch wird ein PPA (Personal Package Archive), das Sie früher manuell als .list hinzugefügt haben, wieder als .sources angelegt.
• Ein Release-Upgrade hat die distributionsseitigen Paketquellen in das deb822-Format umgeschrieben und Ihre manuell erstellte .list-Datei daneben unverändert belassen.

Jeder dieser Wege ist für sich genommen plausibel. Das Duplikat entsteht, wenn zwei davon auf demselben System auftreten, oft mit einem Abstand von mehreren Monaten.

Die beiden Formate im Vergleich

Das alte Format verwendet eine Zeile pro Paketquelle, und jeder Bestandteil hat eine feste Position.

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

Die Reihenfolge ist festgelegt: zuerst der Typ (deb für Binärpakete, deb-src für Quellpakete), dann Optionen in eckigen Klammern, anschließend der URI (Uniform Resource Identifier) des Archivs, die Suite und eine oder mehrere Komponenten. Da die Bedeutung von der Position abhängt, verändert bereits ein Leerzeichen an der falschen Stelle, wie apt den Eintrag interpretiert.

deb822 beschreibt dieselben Angaben als Abschnitt mit benannten Feldern. Der Name stammt aus RFC 822, dem Format für E-Mail-Header, das Debian bereits für Paketsteuerdateien verwendet.

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

Dieselbe Paketquelle, derselbe Schlüssel, keine zusätzlichen Angaben. Die Zuordnung ist direkt: deb wird zu Types, die Archivadresse wird zu URIs, die Suite wird zu Suites, die Komponenten werden zu Components, und jede Option aus den eckigen Klammern wird zu einem eigenen Feld. Damit wird signed-by= zu Signed-By: und arch= zu Architectures:.

Jeder Feldname steht im Plural, weil jedes Feld eine durch Leerzeichen getrennte Liste aufnehmen kann. Suites: noble noble-updates noble-backports in einem Abschnitt ersetzt drei separate deb-Zeilen. Eine Leerzeile beendet einen Abschnitt. Daher kann eine einzelne .sources-Datei mehrere Paketquellen enthalten. deb822 kann außerdem Einstellungen aufnehmen, die das einzeilige Format nur unzureichend unterstützt: Enabled: no zum Deaktivieren einer Paketquelle, Trusted, Check-Valid-Until und einen direkt in Signed-By eingefügten Schlüssel. Dabei muss jede Zeile um ein Leerzeichen eingerückt werden, und Leerzeilen werden als einzelner Punkt geschrieben.

Wo die einzelnen Dateien liegen

• /etc/apt/sources.list: die ursprüngliche einzelne Datei. Unter Ubuntu 24.04 und neuer ist sie normalerweise leer oder enthält nur einen Kommentar, der auf den neuen Speicherort verweist.
• /etc/apt/sources.list.d/*.list: Einträge mit jeweils einer Zeile, normalerweise eine Datei pro Repository.
• /etc/apt/sources.list.d/*.sources: deb822-Abschnitte. Unter Ubuntu 24.04 und neuer liegen die Repositorys der Distribution hier in ubuntu.sources.
• /etc/apt/keyrings/: Hier gehören die von Ihnen hinzugefügten Schlüssel hin. /usr/share/keyrings/ enthält Schlüssel, die aus einem Paket stammen.

apt liest nur Dateien, die mit .list oder .sources enden. Ein Dateiname darf Buchstaben, Ziffern, Unterstriche, Bindestriche und Punkte enthalten. Eine Datei mit einer anderen Erweiterung wird mit einem Hinweis übersprungen. Das ist für die folgende Fehlerbehebung relevant.

Das doppelte Paar finden

Beginnen Sie mit der Verzeichnisauflistung:

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

Zwei Dateien mit demselben Stammnamen und unterschiedlichen Erweiterungen bilden das übliche Paar. Verlassen Sie sich jedoch nicht auf die Namen. Lesen Sie den Inhalt, da sich ein Duplikat in einer Datei mit beliebigem Namen verbergen kann:

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

Das Paar besteht aus den beiden Einträgen mit demselben Host und derselben Suite. Beide verweisen auf https://download.docker.com/linux/ubuntu und die Suite noble. Damit ist dasselbe Repository zweimal eingetragen. Ihre Signed-By-Pfade weichen ebenfalls voneinander ab. Dadurch entsteht der zuvor gezeigte Fehler Conflicting values.

Verwenden Sie für diesen Schritt grep statt eines apt-Befehls. Wenn apt bereits wegen des Konflikts abbricht, kann es Ihre Paketquellen ebenfalls nicht auflisten. Daher gibt apt-cache policy denselben Fehler aus, statt die gewünschte Antwort zu liefern.

Behebung: Die deb822-Datei behalten, die ältere Datei entfernen

Behalten Sie die Datei .sources. Dies ist das Format, das die apt-Werkzeuge inzwischen schreiben, und Debian sowie Ubuntu entwickeln sich beide in diese Richtung. Prüfen Sie vor dem Löschen, welcher der beiden relevanten Pfade auf dem Datenträger vorhanden ist:

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

Nur /etc/apt/keyrings/docker.asc ist vorhanden. Damit enthält die deb822-Datei die gültige Konfiguration, während die Datei .list auf einen entfernten Schlüssel verweist. Falls die Datei, die Sie behalten möchten, den fehlenden Schlüssel nennt, übernehmen Sie zuerst den funktionierenden Pfad in diese Datei. Löschen Sie anschließend die andere Datei.

Verschieben Sie die ältere Datei aus dem Verzeichnis, statt sie direkt zu löschen:

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

Sie können sie auch in docker.list.bak umbenennen und im Verzeichnis belassen, da apt unbekannte Erweiterungen ignoriert. Dann gibt jedoch jeder apt-Aufruf Folgendes aus:

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

Wenn Sie die Datei an einen anderen Ort verschieben, wird diese Meldung nicht mehr angezeigt. Gleichzeitig bleibt die Sicherung erhalten. Eine anschließend korrekte apt update sieht so aus. Sie enthält keine Zeile, in der zwei Dateien genannt werden:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Bestätigen Sie nun, dass das Repository nach der Änderung weiterhin funktioniert:

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

Falls die Dokumentation eines Anbieters weiterhin von der Datei mit einer einzelnen Zeile ausgeht, können Sie diese Datei behalten und stattdessen die Datei .sources löschen. Eine Regel entscheidet in beiden Fällen: Genau eine Datei darf ein bestimmtes Archiv und eine bestimmte Suite deklarieren.

Warum eine defekte Drittanbieterquelle apt update blockiert

Der benachbarte Fehler sieht anders aus, hat aber dieselbe Ursache: eine Drittanbieterquelle, die apt nicht verwenden kann. Die erste Variante ist ein fehlender Schlüssel:

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Das Feld Signed-By fehlt oder verweist auf eine Datei, die keinen verwendbaren Schlüssel enthält. Deshalb kann apt die Signatur der InRelease-Datei des Archivs nicht prüfen. Anschließend verwirft apt das gesamte Repository, statt Paketlisten zu verwenden, deren Integrität nicht geprüft werden kann. Prüfen Sie die Schlüsseldatei selbst:

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

Ein funktionierender Schlüssel gibt eine pub-Zeile mit einer Schlüssel-ID und eine uid-Zeile mit dem Namen des Anbieters aus. gpg: no valid OpenPGP data found. bedeutet, dass die Datei überhaupt kein Schlüssel ist. Meist wurde eine Fehlerseite gespeichert, weil sich die URL des Schlüssels geändert hat. Rufen Sie den Schlüssel erneut ab, prüfen Sie die Datei und führen Sie anschließend apt update aus.

Die zweite Variante tritt nach einem Release-Upgrade auf:

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

Die PPA hat für diese Suite nichts veröffentlicht. Deshalb existiert der Pfad auf dem Server nicht, und die Anfrage liefert 404. Ihre anderen Repositorys werden weiterhin aktualisiert. Bereits installierte Pakete bleiben unverändert. Der Lauf wird jedoch mit einem Status ungleich null beendet. Daher meldet jedes Skript, das den Rückgabestatus von apt update prüft, bei jedem Aufruf einen Fehler. Deshalb sollten Sie eine nicht mehr erreichbare Quelle auf einem System mit konfigurierten unbeaufsichtigten Sicherheitsaktualisierungen entfernen: In den täglichen Meldungen kann sonst ein tatsächlicher Fehler untergehen. Installationsskripte von Anbietern können beide Varianten auslösen. Deshalb sind die meisten Tailscale-Installationsfehler unter Ubuntu letztlich auf einen Schlüsselbund zurückzuführen, den das Skript nie angelegt hat, oder auf einen Release-Codenamen, den das Archiv nicht unterstützt.

Eine Quelle deaktivieren, ohne die übrigen Quellen zu beeinträchtigen

Fügen Sie bei einer deb822-Datei ein Feld zum Abschnitt hinzu und speichern Sie die Datei:

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

Das apt-Handbuch empfiehlt dieses Vorgehen, statt jede Zeile des Abschnitts auszukommentieren. Außerdem lässt es sich leichter rückgängig machen. Bei einer einzeiligen Datei setzen Sie am Anfang der Zeile ein #. Bei beiden Formaten können Sie die Datei auch aus /etc/apt/sources.list.d/ verschieben. Diese Option sollten Sie verwenden, wenn das Repository dauerhaft entfernt wurde.

Führen Sie sudo apt update erneut aus. Der Block Err: für dieses Repository verschwindet. Der Exit-Status ist wieder 0. Dies können Sie in der nächsten Zeile mit echo $? prüfen.

Beheben Sie eine fehlerhafte Quelle niemals mit sudo rm /etc/apt/sources.list.d/*. Unter Ubuntu 24.04 und neuer löscht dieser Befehl ubuntu.sources. Diese Datei enthält die Repositorys der Distribution. apt verfügt dann über keinerlei Paketlisten mehr und meldet für Software, die offensichtlich vorhanden ist, E: Unable to locate package curl. Wenn Sie den Befehl bereits ausgeführt haben, schreiben Sie die Datei wieder:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Speichern Sie dies als /etc/apt/sources.list.d/ubuntu.sources. Ersetzen Sie noble durch den Namen Ihres eigenen Releases aus lsb_release -cs. Führen Sie anschließend sudo apt update aus.

Legacy-.list-Dateien in deb822 konvertieren

Ab August 2026 enthalten apt 3.0 und neuere Versionen einen Konverter dafür. Debian 13 enthält ihn ebenfalls, ebenso Ubuntu 25.04 und jede nachfolgende Version einschließlich 26.04. Prüfen Sie die Version und führen Sie den Konverter anschließend aus:

apt --version
sudo apt modernize-sources

Der Konverter schreibt die einzeiligen Dateien unter /etc/apt/sources.list.d/ als deb822-.sources-Dateien neu. Lesen Sie die Ausgabe. Listen Sie anschließend das Verzeichnis selbst auf und führen Sie apt update aus, bevor Sie dem Ergebnis vertrauen. Ubuntu 24.04 enthält eine ältere apt-Version ohne dieses Unterkommando. Dort lautet die Antwort auf den Befehl E: Invalid operation modernize-sources. Konvertieren Sie die Dateien in dieser Version anhand der oben beschriebenen Feldzuordnung manuell.

Die Konvertierung ist derzeit optional, weil apt weiterhin beide Formate einliest. Auf einem Server, den Sie dauerhaft betreiben möchten, ist sie dennoch sinnvoll. Jedes Tool, das jetzt Paketquellen schreibt, verwendet deb822. Ein System mit ausschließlich .sources-Dateien kann diese Art von Duplikat dadurch nicht mehr erzeugen.

Drittanbieterquellen auf einem Server übersichtlich halten

Drittanbieter-Repositorys altern auf einem Server am schnellsten. Jedes Repository ist ein Versprechen eines anderen Anbieters, weiterhin Pakete für Ihr Ubuntu-Release bereitzustellen. Ein Release-Upgrade prüft all diese Versprechen am selben Nachmittag.

• Fügen Sie ein Drittanbieter-Repository nur hinzu, wenn das Distributionspaket nicht ausreicht. Ein einfacher LAMP-Stack auf Ubuntu 24.04 benötigt keines: Das Ubuntu-Archiv enthält alle verwendeten Pakete und stellt während der gesamten Lebensdauer des Releases Sicherheitsupdates bereit.
• Bewahren Sie Schlüssel in /etc/apt/keyrings/ auf, einen Schlüssel pro Anbieter, mit dem Modus 644. Der unprivilegierte Benutzer _apt lädt die Pakete herunter und muss den Schlüssel lesen können. Eine nur für root lesbare Schlüsseldatei verursacht bei jedem Abruf aus diesem Repository einen Berechtigungsfehler.
• Verweisen Sie in jedem Eintrag mit Signed-By auf genau diese Datei. Ein Schlüssel in /etc/apt/trusted.gpg oder /etc/apt/trusted.gpg.d/ gilt für jedes Repository auf dem Server als vertrauenswürdig. Dadurch kann ein vor Jahren hinzugefügter Anbieterschlüssel Pakete aus beliebigen Quellen validieren.
• Lesen Sie vor einem Release-Upgrade Ihre Paketquellen und prüfen Sie, ob jeder Anbieter bereits Pakete für die Ziel-Suite veröffentlicht.

Ein Schlüssel im alten globalen Keyring macht sich bei jedem Update bemerkbar:

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Exportieren Sie diesen einzelnen Schlüssel in eine eigene Datei und verweisen Sie im Eintrag darauf:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

Fügen Sie Signed-By: /etc/apt/keyrings/docker.gpg zum Repository-Eintrag hinzu und führen Sie sudo apt update aus. Die Warnung verschwindet, sobald kein Repository mehr vom alten Keyring abhängt. Anschließend können Sie den Eintrag mit sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 entfernen.

Eine weitere Gewohnheit erspart Ihnen den größten Aufwand. do-release-upgrade deaktiviert Drittanbieterquellen für das Upgrade und lässt sie danach deaktiviert. Wenn Sie sie anschließend einzeln manuell wieder aktivieren, entstehen dabei leicht doppelte Einträge. Lesen Sie vor dem Start den Upgrade-Leitfaden von Ubuntu 24.04 auf 26.04 und notieren Sie, welche Repositorys Sie weiterhin benötigen. Auf einem gerade erst eingerichteten Rechner ist der günstigste Zeitpunkt für eine saubere Konfiguration der Paketquellen die ersten zehn Minuten auf einem neuen VPS, solange nur die von Ubuntu bereitgestellten Einträge auf dem Server vorhanden sind.

FAQ

Warum meldet apt, dass ein Ziel mehrfach konfiguriert ist?

Weil zwei Dateien unter /etc/apt/sources.list.d/ dasselbe Repository, dieselbe Suite und dieselbe Komponente deklarieren. Die Meldung nennt beide Dateien mit Zeilennummern, zum Beispiel docker.list:1 und docker.sources:1. apt führt sie zusammen und läuft weiter, daher funktioniert das Update weiterhin. Sie sollten den doppelten Eintrag trotzdem bereinigen: Sobald die beiden Dateien unterschiedliche Signaturschlüssel angeben, bricht apt mit E: Conflicting values set for option Signed-By ab und verweigert das Lesen sämtlicher Paketquellen. Dadurch ist auch apt install blockiert.

Sollte ich die Datei .list oder die Datei .sources behalten?

Behalten Sie die Datei .sources. deb822 wird von add-apt-repository unter Ubuntu 24.04 und neuer geschrieben. Das Format enthält für jede Einstellung ein benanntes Feld statt positionsabhängigem Text in eckigen Klammern und entspricht der zukünftigen Richtung der Distributionen. Bevor Sie die Datei .list löschen, prüfen Sie mit ls -l /etc/apt/keyrings/, ob der Pfad Signed-By in der Datei .sources auf einen vorhandenen Schlüssel verweist. Verschieben Sie die alte Datei aus /etc/apt/sources.list.d/ heraus, statt sie innerhalb des Verzeichnisses umzubenennen. Ein verbliebener Name .bak veranlasst apt sonst bei jedem Lauf, einen Hinweis auf eine ignorierte Datei auszugeben.

Wie deaktiviere ich ein apt-Repository, ohne es zu entfernen?

Fügen Sie in einer deb822-Datei .sources die Angabe Enabled: no zum Abschnitt hinzu. Setzen Sie in einer einzeiligen Datei .list ein # an den Anfang der Zeile. Führen Sie anschließend in beiden Fällen sudo apt update aus. Danach verschwindet der Err:-Block für dieses Repository. Das ist die richtige Vorgehensweise, wenn ein Repository eines Drittanbieters noch keine Pakete für Ihre Ubuntu-Version bereitstellt und sein 404-Fehler apt update mit einem Exit-Status ungleich 0 beendet.

Wird das einzeilige sources.list-Format abgeschafft?

Es ist veraltet, wurde aber nicht entfernt. apt liest Dateien .list weiterhin und wird dies noch lange tun. Daher fällt auf Ihrem Server nicht kurzfristig etwas aus. Neue Werkzeuge schreiben deb822: Ubuntu 24.04 und neuer speichern die Distributions-Repositories in /etc/apt/sources.list.d/ubuntu.sources, und add-apt-repository schreibt Dateien im Format .sources. Unter apt 3.0 und neuer konvertiert sudo apt modernize-sources die noch vorhandenen Dateien.