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.

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) Ja, auskommentiert und dann 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 zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf verzichtet.

--GerBra (Diskussion) 10:45, 2. Okt. 2022 (CEST) Dann sollten wir auch auf dieses eigene Logfile verzichten, ich dachte es würde mehr "Müll" geben. Ich passe das preload-Skript dann wieder an.

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)

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) 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)

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ich würde dann (pacman ) PackagePreDownload als Titel/Setup-Intention vorschlagen, wenn eine Abkürzung notwendig ist dann ggf. PPD (obwohls das ein Suchbegriff im Zusammenhang mit Cups/Printer ist).

->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. -- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) 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.

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) 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 und einsam die '-n' Entscheidung gefällt, sorry) Beim Host das '-n' wohl auch wieder zu entfernen. Wir wissen ja nicht ob der Host auch zusätzliche Repos nutzt. Tuxnix (Diskussion) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ich denke es schadet nichts die Host-Listen mittels -n/--native zu exportieren, am Server schlagen dann ja jeweils viel "kleinere" Listen auf. Trotzdem sollte der Server die all-Liste dann nochmal anhand seiner Sync-DB abgleichen vor dem PreDownload (also ich werde die comm -12 blabla wieder einbauen)

Da musste ich jetzt auch schnell sein. Ich schlage vor wir machen jetzt erst einmal alles fertig und ändern den Artikelnamen zu letzt. Um den Namen zu ändern muss man einen neuen Artikel anlegen und Dirk muss den alten Artikel dann wieder löschen. Ich vermeide es ihm mit sowas unnötig viel Arbeit zu machen und schreibe meistens erst auf der eigenen Seite vor, ehe ich veröffentliche. Aber ich war mir hier nicht sicher ob du da überhaupt Schreibrechte hast. _______

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.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Also ich finde es immer gut, wenn ein Wikiartikel initial erklärt um was es eigentlich geht, Überblick über den Ablauf gibt und erst dann die konkrete Implementation aufzeigt. Ohne das der Leser das Grobe eineigermaßen verstanden hat lassen sich auch von ihm keine Anpassungen an **seine** Umgebung vornehmen. Das Einrichten reduziert sich dann leider oft auf das blindlingse/verständnislose Abkopieren der einzelnen Befehle. Ich habe mir mal eine so eine "Textstruktur" für den Artikel überlegt. Ich packe das hier in die Diskussion mal in einen eigenen Abschnitt, ich wollte den momentanen Wiki-Text noch nicht ändern. Du kannst ja mal schauen, ob dir sowas zusagt bzw. auch verbessern.

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.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.

P.S.: Tipp - Viermal ~ erzeugt eine Signatur mit Datumsstempel unter deinem Diskussionsbeitrag. Das ist sehr praktisch wenn man später die Diskussion nachvollziehen möchte. Tuxnix (Diskussion) 13:18, 1. Okt. 2022 (CEST)