ubuntuusers.de

erledigt

Hat sich der Syntax für die Verwendung einer eigenen Paketquelle unter 13.04 (hier Xubuntu) geändert? Speziell dieser Absatz? ...

Um die selbst zusammengestellte Paketquelle in das System einzubinden, wird in der Paketverwaltung folgende Angabe (angenommen, die Pakete befinden sich in ~/Software) gemacht, wobei der Ausdruck <benutzer> durch den Namen des Benutzers zu ersetzen ist ^[3]:

deb file:/home/<benutzer>/Software ./

Bitte die Schreibweise der Quelle genau beachten - nur ein einfacher Slash nach dem file:, alles andere schlägt fehl (s.a. das Debian-Anwenderhandbuch 🇩🇪).

Ich verwende diesen Syntax seit langer Zeit. Bis 12.04 auch ohne Probleme. Unter einer Xubuntu-13.04. Neuinstallation gibt es keine Fehlermeldung beim Einlesen der Quellen (wie es z.B. bei einem falschen Syntax der Fall wäre); die *.list Datei ist vorhanden und o.k. Aber die Quelle bzw. die Pakete selbst werden in Synaptic nicht angezeigt (linke Seite beim Einstellen auf "Ursprung"). Unter /Einstellungen/Paketquellen/ existiert jedoch der korrekte Eintrag.

Ich sollte erwähnen, dass meine Paketquelle nicht signiert ist. Bei Installation/Aktualisierung via Synaptic ließen sich die Pakete - nach einem Warnhinweis - allerdings bisher immer problemlos installieren.

EDIT

Es können Pakete mit "sudo apt-get install" aus meiner Paketquelle installiert werden, daher ist diese offensichtlich korrekt eingebunden aber in Synaptic unsichtbar. Unter 13.04 läuft Synaptic 0.80, unter 12.04 die Version 0.75.9.

Kann die Unsichtbarkeit von unsignierten Paketquellen in Synaptic 0.80 von jemanden bestätigt werden? Bzw. gibt es eine Option diese wieder sichtbar zu machen?

/EDIT

Leider jetzt als fehlerhaft markiert:

Man kann so zwar eine eigene Paketquelle anlegen, diese aber nicht benutzen! Apt verarbeitet inzwischen nur noch signierte Quellen und man benötigt auch eine Release-Datei.

kB schrieb:

Man kann so zwar eine eigene Paketquelle anlegen, diese aber nicht benutzen! Apt verarbeitet inzwischen nur noch signierte Quellen und man benötigt auch eine Release-Datei.

Ich kann das hier gerne testen und zu verbessern suchen. Kannst Du mir vielleicht noch nähere Informationen zur Verwendung einer Release-Datei geben?

Außerdem würde ich ein Howto/ hieraus machen.

apt kennt --allow-insecure-repositories, für eigene Paketquellen vielleicht ein Workaround, wenn man die public machen möchte, weniger.

Zur Release-Datei (bzw. eigenes Repo) hatte ich etwas gelesen, aber selbst noch nicht probiert:

• debian-handbook.info: 15.3. Ein Paket-Depot für APT erstellen

verdooft schrieb:

apt kennt --allow-insecure-repositories, …

Soweit ich das verstehe, gilt diese Option dann allerdings für alle Paketquellen – das kann ja nicht gewollt sein. Oder liege ich falsch und man kann es auf das eigene Repo beschränken?

fleet_street schrieb:

Zur Release-Datei (bzw. eigenes Repo) hatte ich etwas gelesen, aber selbst noch nicht probiert:

• debian-handbook.info: 15.3. Ein Paket-Depot für APT erstellen

Danke für den Hinweis! 👍

Ich bin meiner Einschätzung nach mit der Überarbeitung Neufassung fertig und bitte um Rückmeldung.

karzer schrieb:

Ich bin meiner Einschätzung nach mit der Überarbeitung Neufassung fertig und bitte um Rückmeldung.

Das liest sich jedenfalls schon mal gut und plausibel. Zum Ausprobieren bin ich noch nicht gekommen.

Drei Details sich mir aber bereits beim Lesen aufgefallen:

1. Dem Artikel fehlt ein Abschnitt „Installation“: gpg und gzip sind bei Ubuntu standardmäßig vorhanden, dpkg-dev muss zusätzlich installiert werden.

2. Warum soll das Paket in den Ordner ~/Software/ verschoben werden und anschließend nach ~/Software//apt-repo/pool/main/ kopiert werden? Reicht die Ablage in ~/Software//apt-repo/pool/main/ nicht aus?

3. Der Artikel reprepro verweist auf Eigene Paketquelle anlegen für den Fall, dass man eine unsignierte Paketquelle verwenden möchte. Deine Neufassung (Danke dafür!) enthält nun aber eine Signierung. Vermutlich ist die Information in reprepro veraltet, und die Verwendung unsignierter Paketquellen gar nicht mehr möglich – eine dumme Idee war sie schon immer. Die Beziehung der beiden Artikel sollte aber geklärt und erklärt werden.

Danke für die Rückmeldung! Ich habe Deine Anregungen eingearbeitet und noch einige wichtige Ergänzungen vorgenommen. Bitte auf Plausibilität prüfen.

kB schrieb:

[...] Der Artikel reprepro verweist auf Eigene Paketquelle anlegen für den Fall, dass man eine unsignierte Paketquelle verwenden möchte. Deine Neufassung (Danke dafür!) enthält nun aber eine Signierung. Vermutlich ist die Information in reprepro veraltet, und die Verwendung unsignierter Paketquellen gar nicht mehr möglich – eine dumme Idee war sie schon immer. Die Beziehung der beiden Artikel sollte aber geklärt und erklärt werden.

Ich habe einen entsprechende Information in den Artikel eingefügt, bin aber für eine Änderung der Formulierung in reprepro. Danke für den Hinweis.

Hallo,

gibt es von Dir, kB, oder anderen noch weitere Rückmeldung, damit der Artikel bald verschoben werden kann?

Einige Kleinigkeiten:

1. gpg und gzip sind Standard-Pakete bei Ubuntu und müssen daher nicht installiert werden. Die Wiki-Artikel GnuPG und gzip aber verlinken. GnuPG ist bereits im Wissensblock, gzip kann dort noch ergänzt werden.

2. Was formal auch noch fehlt, sind Links aus dem Text in den Wissensblock.

3. Welcher Ordner genau wird später die Wurzel einer übers Netzwerk zugänglichen Paketquelle? Ich vermute …/apt-repo/, aber das sollte noch klar gesagt werden. Auf keinen Fall darf man …/Software/ freigeben, da dann der private Schlüssel veröffentlicht würde. Davor sollte man warnen.

4. Im Skript am Ende fehlt wohl die Erzeugung des neuen Schlüsselpaars.

Alternativ zur individuellen Erzeugung eines Schlüsselpaars für jede Paketquelle kann man natürlich auch einen Schlüssel für mehrere Paketquellen verwenden. Daher müsste ins Skript eine Abfrage, welcher Schlüssel verwendet werden soll und bei einer Antwort „neu“ wird eben ein neuer erzeugt.

kB schrieb:

Einige Kleinigkeiten: [...]

Vielen Dank dafür!

[...] Was formal auch noch fehlt, sind Links aus dem Text in den Wissensblock. [...]

An welche hättest Du denn da gedacht? So viele sind es ja nicht..

[...] Welcher Ordner genau wird später die Wurzel einer übers Netzwerk zugänglichen Paketquelle? Ich vermute …/apt-repo/, aber das sollte noch klar gesagt werden. Auf keinen Fall darf man …/Software/ freigeben, da dann der private Schlüssel veröffentlicht würde. Davor sollte man warnen. [...]

Ich habe einen Warnhinweis eingefügt, danke für die Rückmeldung!

[...] Im Skript am Ende fehlt wohl die Erzeugung des neuen Schlüsselpaars.

Alternativ zur individuellen Erzeugung eines Schlüsselpaars für jede Paketquelle kann man natürlich auch einen Schlüssel für mehrere Paketquellen verwenden. Daher müsste ins Skript eine Abfrage, welcher Schlüssel verwendet werden soll und bei einer Antwort „neu“ wird eben ein neuer erzeugt.

Das Skript am Ende ist zur Automatisierung der Vorgänge angelegt, wenn ein neues Paket hinzugefügt wird, also die Neugenerierung der entsprechenden Dateien unter dists/. Das heißt, dass der bereits bestehende Schlüssel importiert werden muss, um keine Veränderung der Signatur zu bewirken.

Meinst Du, eine Anpassung des Skripts, um auch die Neuerstellung einer Paketquelle abzudecken, wäre sinnvoll?

karzer schrieb:

[…]

[...] Was formal auch noch fehlt, sind Links aus dem Text in den Wissensblock. [...]

An welche hättest Du denn da gedacht? So viele sind es ja nicht..

Es sind Formalien, deren Missachtung den Artikel nicht schlecht machen würde. Ich bestehe also nicht darauf.

[…] Das Skript am Ende ist zur Automatisierung der Vorgänge angelegt, wenn ein neues Paket hinzugefügt wird, also die Neugenerierung der entsprechenden Dateien unter dists/. Das heißt, dass der bereits bestehende Schlüssel importiert werden muss, um keine Veränderung der Signatur zu bewirken.

Das kannst Du natürlich so halten, aber beim Lesen des Artikels hat sich bei mir eine andere Erwartungshaltung aufgebaut. Also Hinweis.

Meinst Du, eine Anpassung des Skripts, um auch die Neuerstellung einer Paketquelle abzudecken, wäre sinnvoll?

Das eine ist so sinnvoll wie das andere. Deine persönliche Neigung entscheidet.

Hallo,

ich habe eben eine aktualisierte Fassung des Skriptes in den Artikel eingefügt (und die Links-Sektion etwas erweitert). Bitte gerne testen und Kritik üben.