Alternativ könntest du für die Download-Aktion(also den -w Teil) im Procedere auch eine eigene Sync-Datenbank verwenden (Option -b/--dbpath bei pacman).
Das setzt dann aber ein explizites -y/--refresh beim realen Upgrade-Vorgang voraus (machst du ja schon).
Vorteil des Verfahrens: Deine reale Sync-Datenbank (/var/lib/pacman/sync wäre unangetastet und immer noch auf dem Stand des letzten Syncs vom "realen" Upgrade/Install-Vorgang. Und: ein (warum auch immer) gemachtes pacman -S foobar würde dann maximal ein "Paket not found" auf dem Spiegelserver erfahren, aber eben kein teilweises, unvollständiges System.
//Edit: Der "rote Kasten" gilt m.E. immer noch, aber weniger durch den Pre-Download-Vorgang an sich sondern durch die Gefahr das der User dadurch in die Gefahr eines partiellen Upgrades getrieben wird. Bei einer gemeinsam genutzten Sync-Datenbank ist ein - gedankenloses, "wissenloses" - pacman -S foobar natürlich absolut No-Go!
Der User muß halt verinnerlichen daß einem separatem (-Sy) unbedingt immer ein -Su folgen muß, auch wenn nur ein neues Paket installiert werden soll.
Und alles was dem User hilft solche Situationen zu vermeiden ist IMHO gut. Also in punkto separatem Download (-w= wäre ich für die Anleitung/Hinweis mit einer extra Sync-Datenbank für diesen Vorgang - wie es andere Tools die eine aktuelle Sync-DB brauchen wie checkupdates z.B. schon machen/anbieten.
//Edit2: Hier Beispiele
Als Beispiele zwei Szenarien:
a) Für den lokalen Rechner sollen die jeweils aktuellen Pakete heruntergeladen werden und für eine spätere Aktualisierung im Cache vorhanden sein. Das ist dein avisiertes Beispiel.
b) Es gibt im Netzwerk drei Rechner: einer mir Gnome, einer mit KDE und ein "Server". Alle Rechner nutzen einen gemeinsamen Paket-Cache. In diesem sollten alle jeweils benötigten Pakete vorab schon runtergeladen sein, also beim jeweiligen -Syu am jeweiligen Rechner schon verfügbar sein. Der "Server" soll sich um diesen Pre-Download kümmern.
Generell gilt:
- Es sollen an keinem Rechner durch den Vorgang Änderungen (aka "automatische Upgrades") durchgeführt werden. Es geht lediglich um den Pre-Download von jeweils dem aktuell verfügbaren Paket.
- Alle Rechner sollen konsistent bleiben in ihrem Zustand seit dem letzten -Syu Upgrade-Vorgang.
- Ziel ist es jeweils nur den Paket-Cache mit den aktuell verfügbaren Paketen zu beschicken. Und das eben ohne Punkt (2) oben zu verletzen.
Grundvoraussetzug bei allen Szenarien ist:
Eine eigene Lokalität für die pacman Sync-Datenbank, wegen Punkt (2).
Bei pacman ist die Sync-Datenbank per Default /var/lib/pacman. Darin sind die Ordner local und sync.
Ein pacman -Sy verändert den Inhalt von sync, ein -Su den Inhalt von local. Beides zusammen (-Syu) bilden ein ordentliches Systemupgrade.
Eine eigene Sync-Datenbank wird z.B. so erstellt:
# mkdir /var/local/pacman-DL
# ln -s /var/lib/pacman/local/ /var/local/pacman-DL/
Ein Update der Sync-Datenbank per
pacman -Sy --dbpath /var/local/pacman-DL
verändert nun lediglich unser extra Sync-Dir, läßt aber das "reale" Sync dir "in Ruhe".
Für Szenario a) Pre-Download nur für einen PC würde sich nun anbieten:
- Ein cronjob/systemd-timer mit:
pacman -Syuw --dbpath /var/local/pacman-DL
Die (extra) Sync-DB würde auf den aktuellen Stand gebracht und gleichzeitig der Paket-Cache mit den verfügbaren aktuellen Paketen befüllt.
- Das eigentliche Upgrade dann mit:
pacman -Syu
Die Pakete, die in der aktuellen Version im Paket-Cache schon vorhanden sind müßten nicht von den Spiegelservern runtergeladen werden.
Vorteil/Ziel wie gesagt: Der Zustand zwischen zwei Upgrades bliebe konsistent, es würden am PC weder die Sync-DB noch die DB der installierten Paket(e)/Versionen angetastet durh den Pre-Download. Um das Standard pacman.log noch frei von Einträgen zu halten, die nur durch die Pre-Download-Aktionen kommen würde sich anbieten, im Job ein eigenes Log zu verwenden, also z.B.:
pacman -Syuw --dbpath /var/local/pacman-DL --logfile /var/local/pacman-DL/pacman.log
Szenario 2)
Mehrere Rechner mit teils unterschiedlichen Paketgruppen, ein Rechner soll den Pre-Download für alle durchführen und einen gemeinsamen Paket-Cache befüllen vor den jeweils individuell getätigten "realen" Upgrade-Vorgängen der Rechner.
Das erfordert ein wenig mehr "Vorarbeit", v.a. um das Ziel "Konsistenz" und Vermeidung von partiellen Ugrades zu erreichen.
Wir nehmen an, der "Server" soll die Pakete pre-downloaden. Für sich selbst, den Gnome-Rechner und den KDE-Rechner; in das Paket-Cache Verzeichnis /var/cache/pacman/pkg (was irgendwie von allen genutzt wird (NFS/SMB)).
Ich habe es jetzt nicht ausprobiert, sollte aber so funktionieren:
a) am Server ist wie oben für den Pre-Download ein eigenes Sync-DB einzurichten.
b) Die beteiligten Rechner legen eine Liste ihrer jeweils installierten Pakete z.B. ins gemeinsam genutzte Paket-Cache-Dir ab:
pacman -Qq > /var/cache/pacman/pkg/<rechnername>.list
Das kann z.B. durch einen pacman-Hook nach dem jeweils erfolgten "realen" -Syu-Upgrade am jeweiligen Rechner geschehen.
Der "Server", der Gnome-Rechner und der KDE-Rechner haben also unterschiedliche Listen mit jeweils installierten Paketen, die möglichst auch alle pre-downloaded werden sollen.
c) Am "Server" - der downloaded - werden diese Listen nun zusammengeführt und vereinheitlicht vor dem eigentlichen Pre-Download. Dafür würde sich ein eigenes Skript anbieten:
sort -u /pfad_zum/<pc-1>.list /pfad_zum/<pc-2>.list /pfad_zum/<pc-3>.list > /pfad_zum/complete.list
Das erzeugt eine Liste aller Pakete von allen Rechnern für die jeweils die aktuelle Version pre-downloaded werden soll (/pfad_zum/complete.list). Das -u/--unique bei sort bewirkt, das Pakete die auf allen 3 Rechnern installiert sind nicht mehrmals in der complete-Liste auftauchen.
pacman -Syw --dbpath /var/local/pacman-DL - < /pfad_zum/complete.list
Dieser Befehl würde nun die jeweils aktuelle Version aller Pakete aus der complete-Liste pre-downloaden und ins gemeinsame Paket-Dir ablegen.
Wenn die Einzel-Rechner dann ihre jeweils "realen" Upgrades per -Syu machen sollten dann z.B. für den Gnome-Rechner die meisten aktuellen zu installierenden Pakete schon vorhanden sein, ebenso die für den KDE-Rechner. Das halt jeweils ohne unsere Konsistenz-Vorgabe oben zu verletzen.
Das beschreibt für dieses Szenario nur den Idealfall. Was meistens noch berücksichtigt werden muß sind:
1) AUR oder lokal installierte Pakete (die also in den Repos nicht existieren)
Diese kann man z.B. mittels
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list ) > /pfad_zum/complete.list
//Edit: obiges erzeugt eine leere Datei, deshalb besśer sowas:
cp /pfad_zum/complete.list /pfad_zum/complete.list.org
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list
rausfilter bei obigem Punkt (c). Das entfernt aus der complete-Liste eben alle Pakete, die in der eigenen Sync-DB nicht verfügbar sind, also nicht pre-downloaded werden können.
2) Eigene bzw. Fremd-Repos
Falls die beteiligten Rechner sowas nutzen, dann müßte der Rechner der die Pre-Downloads tätigt diese natürlich auch "kennen". Das würde funktionieren wenn dieser eine pacman.conf und ggf. Mirrorlist-Dateien hätte, zusammengefaßt aus allen Repos der beteiligten Rechnern.
Spätestens hier (um die Konsistenz nicht zu ruinieren) ist es sinnvoll, für den pacman der lediglich die Pre-Downloads macht für diese eine eigene pacman.conf dafür anzulegen(Repos) und ggf. auch spezielle Mirrorlist-Datei nnur für diesen Pre-Download-Vorgang.
Der Pre-Download pacman würde dann z.B. per pacman -Syw --config <eigene Conf>
gestartet, in dieser Conf wäre dann der eigene DBPath wie oben konfiguriert und Fremd-Repos eingetragen, ggf. auch andere Mirrorlists. Das halt, um den Download-Rechner (im Beispiel der "Server") sauber zu halten für seinen eigenen Update-Vorgang (bei dem dann die Standard-pacman.conf etc. genutzt wird).