Diskussion:Package-Preload (Beispiel)

Erledigte Diskussions-Themen

(bitte alles hier rein kopieren was deiner Meinung nach erledigt ist. Ich habe mir schon mal erlaubt damit zu beginnen. Falls ein Punkt wieder zu Diskussion gestellt werden muss, dann kopiert man ihn halt wieder nach unten)

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.

Loginfile

- 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.

Artikel editieren

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Prima! 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)

Namen der Variablen

• 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).

GerBra 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! Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):

Namen des scripts

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Die Anpassung des scripts fehlt noch.

GerBra (Diskussion) 07:06, 3. Okt. 2022 (CEST) Ok, ich ändere das jetzt mal auf pkgpredownload.sh

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)

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen: Im script für den server die comm... Zeile setzen, das verhindert auch, dass der User eine Anzeige von z.B. AUR-Paketen zu sehen bekommt wenn er das script auf der Konsole testet. Das würde ihn m.M.n. nur irritieren. Der Hook für den client darf aber so bleiben mit der -n Option!

NFS-Clients

GerBra (Diskussion) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0
gemountet. Das würde real dann aber nicht funktionieren, da daß neuen Cache-Verzeichniss dann auch als CacheDir in die jeweilige pacman.conf geschrieben/editiert weren muß.

Weiter unten beim Hook exportierst du die Pakeltliste aber nach:
/var/cache/pacman/pkg/$HOSTNAME.list
also **nicht** in das gemeinsame Cache-Verzeichnis...

Wir sollten uns im Artikel auf das gem. Cache-Verzeichnis einigen, und dem User den Hinweis geben das ggf. bei anderem Mount-Point seines Setups die pacman.conf anzupassen ist (wenn er/sie/es nicht schon längst getan hat) Ich würde als Einhängepunkt /var/cache/pacman/pkg vorschlagen, da daß die wenigsten Änderungen bedarf. Der NFS-Mount wird dann halt über das bestehende Cache-Dir eingehängt, daß schadet aber nicht. Und Wenn (Laptop) mal der Server nicht verfügbar wäre können die Clients trotzdem ohne Änderungen Updates fahren.

Überhaupt: Nach Abschluß des Artikels (vor der "Freigabe") muß das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf...

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ups! wo kommt denn das nfs bei '<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0' her? Ich mache das nfs sofort weg! Kann man so nicht stehen lassen.

Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!

Syntax Fehler bei pacman -Syuw

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

Tuxnix (Diskussion) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen. Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.

Die Listen haben bisher gar keine Funktion - stimmt das?

GerBra (Diskussion) 07:20, 3. Okt. 2022 (CEST) Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.

Ich werde mal testen, ob ein Paket, dass ausschließlich auf dem client installiert ist, nach seiner Deinstallation vom gemeinsamen paket-cache oder vom mirror geladen wird.

Die Diskussions-Struktur hier im Wiki

PPS: Diese "Kommentare" in die Diskussions-Struktur wild reinzuschreiben ist IMHO irgendwie unübersichtlich. So ist nicht ganz klar wer was sagt (mein neuer text geht in deinen alten über, wie hier ).

Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ich habe mal Überschriften zu den Einzelthemen gesetzt und mir erlaubt ein wenig zu sortieren. Dinge die du für erledigt betrachtest, kannst du dann ganz oben anfügen. Wenn ein Thema wieder gehoben werden muss, kann man es auch wieder unten anfügen. Wenn du beim Abrufen der Wiki auf der Seite 'Letzte Änderungen' nicht auf den Artikellink sondern direkt darunter auf z.B. '12 Änderungen' gehst, dann siehst du sofort was neu editiert wurde und du musst dann auch nicht mehr alten Kram durchlesen. Das klappt auch bei den Diskussionen.

____

Noch zu erledigen

Namen der Seite

GerBra (Diskussion) 11:55, 2. Okt. 2022 (CEST) 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.

Tuxnix 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.

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ja, merken wir uns "PackagePreDownload" schon einmal als Seitentitel vor. Wenn wir einen neuen Artikel anlegen, (man muss den Namen nur in die Suche eingeben, dann muss man wenn man eiggelogged ist nur auf den Link klicken), dann wird aber etwas später auch hier die Diskussion gelöscht. Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.

Besserer Einleitugstext

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.

Artikel Struktur "Vorwort"

PackagePreDownload

1. Übersicht

Ein grosser Teil der Zeit bei einem Systemupdate mittels pacman -Syu vergeht beim Download der Pakete. In einer Forumsdiskussion¹ kam nun die Idee auf, diese Zeit zu verkürzen dadurch, dass die aktuellen Pakete schon vorher von den Spiegelservern heruntergeladen werden. Diese also dann beim eigentlichen Systemupdate im pacman-Paketcache schon vorhanden sind.

Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.

Der PreDownload von Paketen wird mittels der pacman-Option -w/--downloadonly realisiert, ein pacman -Syuw würde also die Repositorien-Sync-Datenbank(-y) aktualisieren, -u würde die zu aktualisierbaren Pakete erfassen. Durch -w/--downloadonly erfolgt im Zuge des Befehls nun aber kein Systemupdate, sondern es werden lediglich die aktualisierbaren Paketdateien heruntergeladen um im pacman-Paketcache (Default: /var/cache/pacman/pkg) abgelegt. Ein weiteres pacman -Syu (ohne -w) stösst nun das wirkliche Systemupgrade an, wobei im Idealfall eben der größte Teil der notwendigen Paketdateien schon vorhanden sind.

Bei einem angestrebten Setup mit mehreren Rechnern, die jeweils ganz unterschiedliche Softwarebestände haben können, gibt es nun ein paar Dinge, die erfüllt sein müssen:

• Alle Rechner müssen einen gemeinsamen Paketcache verwenden.
• Dieser gemeinsame Paketcache muss im Netzwerk für alle beteiligten Rechner lese- und schreibar sein. Eventuell habt ihr bei mehreren Rechnern schon so eine Lösung, ansonsten wird im Artikel die Freigabe mittels NFS vorgestellt.
• Einer der Rechner kümmert sich in bestimmten Intervallen um den Pre-Download der Pakete, wir bezeichnen diesen als "Server". Die Rechner, die vom Pre-Download profitieren sollen sind "Clients".

Das unten aufgeführte Setup funktioniert folgendermassen:

• Die "Clients" exportieren ihre unterschiedlichen (z.B ein KDE-Rechner, ein Gnome-Rechner) Liste der installierten Pakete in das gemeinsam genutzte Paketcache-Verzeichnis. Das geschieht automatisch über einen pacman-Hook.
• Der "Server" erzeugt nun eine gemeinsame Liste aller Pakete, die auf allen Rechnern jeweils installiert sind. Anhand dieser Liste erfolgt dann der Pre-Download dieser Pakete. Der "Server" verwendet, um die Gefahr eines partiellen Upgrades, das die Konsistenz des Systems bei einen unbedachten pacman -S foobar beschädigen könnte zu vermeiden, für den Pre-Download der aktuellen Pakete eine eigene Sync-Datenbank.
• Sobald nun einer der beteiligten Rechner "sein" Systemupdate anstösst mittels pacman -Syu sind eben ein Großteil der Pakete für diesen Rechner schon vorhanden. Das -y (Aktualisierung der Repositorien-Datenbank) ist trotzdem notwendig um aktualisierte Pakete zwischen diesem Upgrade und dem Pre-Download-Vorgang zu erfassen.

2. Implementierung (bisheriger Wiki-Artikel)

3. Fallstricke / Fehlergefahren AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.
paccache gegen explodierende Festplatten

4. weiterführende Links
¹ Forums-Thread
pacman / pacman Tips (ggf. auf .org) ?

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Die Überschriften zu 1. und 2. braucht man nicht. Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.

3. Autsch s. unten.

4. Ja. Das mach ich sofort.

Zu 1. Der Text ist klasse, aber mein Stil ist das nicht. Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.

GerBra (Diskussion) 07:31, 3. Okt. 2022 (CEST) Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft".

Tuxnix Ich persönlich bin im Laufe meiner Wiki-Artikel-Erstellerei dazu übergegangen es möglichst kurz zu halten. Viel Text macht es nicht immer einfacher und der User soll auch nicht davon Abgehalten werden sich selbst Gedanken zu machen. Denn die eigen Suchprozesse sind das, was hinterher im Gedächtnis bleibt. Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link. Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!

GerBra (Diskussion) 07:31, 3. Okt. 2022 (CEST) Ah, nein! Den Schuh laß ich mir nicht anziehen ;-) Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload). Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.

Tuxnix (Diskussion) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.

Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile. Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde. Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest.

--GerBra (Diskussion) 18:05, 4. Okt. 2022 (CEST) Hmm, was soll ich denn deiner Meinung nach "gerade editiert" haben was du "alles wieder rückgängig" machen würdest? Ich bin mir keiner "Schuld" bewußt... Meine letzte Änderung an der Seite betreffen den Namen des predownlaod-Skripts. Aber ohne "böse" zu sein - bitte, bitte "übernimm die Regie". Ich habe an Wikis keinerlei Interesse. Es war deine Idee mit dem Artikel, ich wäre wohl nichtmal auf die Idee gekommen für sowas nen Artikel zu machen. Du/Ich - wir wollen ja beide auch wohl mal zu einem Abschluss kommen. "Technische Fragen" o.ä. sofern noch was unklar helfe ich jederzeit gerne, aber nach 8 Stunden Arbeit kostet mich das mittlerweile zu viel meiner Freizeit. Ich bin mittlerweile auch in einem Alter das ich so eine Entscheidung auch problemlos treffen kann ;-) Kein Stress zwischen uns, ok?------

Tuxnix (Diskussion) 13:53, 5. Okt. 2022 (CEST) Gut, morgen, wenn ich wieder Zeit habe, schreib ich es dann wieder um. Sorry es wird wieder ungarisch werden. Schuld? Nein ganz und gar nicht. Ganz im Gegenteil. Das ist alles richtig prima was du machst. Es ist eher mein Versagen bzw. meine Schwäche an dem Punkt. Ich bin Legastheniker und habe wenig photographische Fähigkeiten bei der Schriftsprache zur Verfügung. Ich kann, wenn die Zeilen so dicht wie jetzt im Script sind, kaum noch etwas auseinanderhalten. Zudem arbeitet mein Kopf etwas über-assoziativ. Die Variablen wirken auf mich jetzt, wie kleine Geschichten 'pkgpredownload'. Die Kommentare erzählen auch eine Geschichte. Und der Programmcode erzählt mir das Gleiche auch noch einmal. Wegen der Teilredundanz und der Phasenverschobenheit der Informationen lande ich in einer Art Assoziationsstrudel. Das alles ist nichts Schlimmes, ich muss damit zurechtkommen, aber ich sollte dann nicht selbst an so gestalteten Texten mitarbeiten, weil ich dann auch nicht mehr erkennen kann, wo sich Fehler eingeschlichen haben. Deshalb bleibt bei der Textgestaltung der Anleitung nur der Weg, dass dies nur einer von uns beiden macht.

Kein Stress zwischen uns! Ja das ist mir auch das aller Wichtigste. Und es sollte uns beiden auch weiterhin miteinander Spaß machen. Ich bin schon etwas älter und die Aktivitäten hier, sollten ein schönes Nebenbei bleiben.

Tuxnix (Diskussion) 15:02, 6. Okt. 2022 (CEST) Habe einige deiner Formulierungen sehr schön mit einbauen können. Und noch eine Schleife bei den Listen behoben. Damit deinstallierte Pakete nicht immer wieder in die Listen kopiert werden.

Testen

GerBra Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ups! wo kommt denn das nfs bei '<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0' her? Ich mache das nfs sofort weg! Kann man so nicht stehen lassen.

Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!

Tuxnix (Diskussion) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.

Tuxnix (Diskussion) 15:02, 6. Okt. 2022 (CEST) Habe das script derzeit deaktiviert und teste gerade im Detail ob und vor allem wie es zu partiellen Upgrades kommen könnte, real mal durch. Je nach Erkenntnis kann man dann das script darauf testen.

Umstellung

Tuxnix (Diskussion) 17:28, 15. Okt. 2022 (CEST) Es gibt zwei Dinge, die mit der Implementation durch Listen so nicht so gut laufen. 1.Bei jedem Durchlauf werden alle installierten Pakete erneut auf Integrität geprüft. Das sind bei mir über 1600 Pakete die jedes mal erneut geprüft werden müssen. Das erzeugt eine Menge Overhead.

2. Deinstallierte Pakete werden nicht automatisch wieder von den Listen genommen, das heißt, sie erfahren weiterhin package upgrades obwohl sie gar nicht mehr genutzt werden.

Ich bin deshalb ganz von den Listen weg. Es gibt jetzt für jeden Rechner eine eigene Paketdatenbank für das zentral durchgeführte Paketupgrade.