Diskussion:Package-Preload (Beispiel)

Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):

- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)

- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.

-- Kommentar Tuxnix: Ja, auskommentiert und einfach einfach nur (if needed) an die Überschrift hängen. Oder als Kommentarzeile hinter der Befehlszeile einfügen. #(if needed) --logfile blal, bla... .Das Loggen vom Sync zeigt aber nicht einmal auf welche Pakete aktualisiert wurden. Das hat nur den Zeitpunkt der einzelnen Syncs aufgelistet. Deshalb habe ich dann darauf verzichtet.

Generell noch ein paar Dinge:

• Die Bezeichnung für die Wiki-Seite bzw. das Prozedere

Genaugenommen müßte statt (Package)Preload eher PreDownload verwendet werden, oder ein anderer treffender Begriff. preload ist ein anderer Vorgang, dazu gibt es hier auch eine eigene Wiki-Seite. Sowas wie "PackagePreDownload"? Das sollte dann aber auch in allen Scripts einheitlich verwendet werden.

• Im preload.sh (ggf. andere Stellen auch)

-- Kommentar Tuxnix: Ja! Und wenn dann einheitlich. Vielleicht auch als Akronym wenn es viel zu lange wird. ich schlage deshalb so was wie 'ppd' vor. (Gute Benennungen zu finden ist gar nicht immer so einfach)

->tuxnix: Ich würde vorschlagen im Skript die sog. "Ungarische Notation" für Variablen-Bezeichner zu vermeiden. Also ListDir, PreLoad_DB. Gerade in Shell-Skripts. Irgendwann schleichen sich so Fehler wie list_dir oder Listdir ein, also bei der Schreibweise. Der bessere und sichere Stil wäre: Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb Konstanten mit Großbuchstaben am Anfang oder komplett. Das macht jedes Skript lesbarer und weniger fehleranfällig. -- Kommentar Tuxnix: Ja, umbedingt!

Exportliste der Hosts / Filtern von AUR/Fremd-Paketen

Meine Gedanken zu Änderung wie diese behandelt werden.

Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante: pacman -Qqn > $HOST.list zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts. -n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten. Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"

Überlegung: --native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist. M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb: "2) Eigene bzw. Fremd-Repos" https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7

Wenn an einem Host z.B. das Testing-Repo aktiv ist und ggf. noch weitere (in)offizielle Repos, dann wandern beim Export mittels --native diese Pakete in die Host.list - da ja am Host in der SyncDB vorhanden.

Der Server kennt diese Pakete aber dann nicht (Repos nicht definiert) bzw. predownloaded ggf. andere als die gewünschten/erwarteten Pakete. Da diese ja nicht im (eigenen) Sync-DB des preload.sh Skripts sind. Es hagelt also ggf. etliche "package not found" Meldungen - obwohl eigentlich die Hosts und der "Server" alles "richtig" machen.

Es wäre wirklich zu beobachten, ob sowas zu einem "Problem" wird. Dann wäre es ggf. doch sinnvoller, die all(package).list die an pacman -Syuw verfüttert wird wieder **zentral** am "Server" zu bereinigen von nichtbekannten (in der eigenen Sync-DB des Servers) Paketen (mittel des:

comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list

Befehls. Die Hosts können ja weiterhin ihre Paketliste mittels: "pacman -Qqn" exportieren, ergibt ja eine "kleinere" Liste, aber wir schalten nochmal eine "zentrale" Instanz am Server dazu.

-- Kommentar Tuxnix: Ja, das macht Sinn und ist auch ein wichtiges Argument dafür deine wunderschöne Zeile wieder einzufügen. (Ich musste im Forum die Diskussion abkürzen, deshalb hab ich so flux die '-n' Entscheidung einsam getroffen) Ich schlage auch vor im Hook für den Host das '-n' wieder zu entfernen. Wir wissen ja nicht ob der Host auch zusätzliche Repos nutzt. _______

Herzlich willkommen in der Arch-Wiki

Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten. Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln. Damit der gemeinsame Wissensaustausch nicht plötzlich abbricht, kann man ja erst einmal nur den Wiki-Artikel hier in der Wiki positionieren und bei der Diskussion schauen wie sich das organisch entwickelt.

Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;) Meinerseits macht mir das auch viel Spaß. Alles was ich über Linux weiß, hab ich mir allein aus dem Internet zusammengesucht. Ich habe auch nur privat mit IT zu tun. Ich lerne durch die Zusammenarbeit mit dir viel dazu. Auch gibt es viele Aspekte die man allein übersehen würde.

Zum Inhalt

Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben. Wir müssten uns noch darüber verständigen ob die Anleitung alle Möglichkeiten beinhalten soll oder ob der Artikel lediglich pur und ohne viele Extras lediglich das Prinzip aufzeigen soll eine eigene Sync-Datenbank zu implementieren.

Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen. Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:

- # Logfile Synx-DB (if needed) - #${SyncDb.log} ...blah blah

Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?) Dann kommen wir uns nicht gegenseitig in die Quere.

P.S.: Tipp - Dreimal ~ erzeugt einen Datumsstempel unter deinem Diskussionsbeitrag. Das ist sehr praktisch wenn man später etwas nachvollziehen möchte.

Tuxnix (Diskussion)