Für mich war das Packman-Repo bei den Multimedia-Codecs immer sehr wertvoll - es wäre sehr schade, wenn das einfach verschwindet 
Seltsamerweise steht auf der Packman-Homepage noch garnichts davon 
Eine komplette Übernahme wäre mir erstmal eine Nummer zu groß, aber ich könnte mir schon vorstellen, den Betreiber ein bißchen unter die Arme zu greifen. Vielleicht hat ja hier von den Erfahrenen oder erleuchteten Anfängern 
noch jemand Lust ?
Früher hatte ich auch nur 1-Gbit-Netz - da habe ich Differenz-Sicherung mit rsync (mit der Option --link-dest) als ziemlich effektiv erlebt, da nur Prüfsummen und die Änderungen übers Netz müssen.
Auch in Deinem Setting könnte es sinnvoll sein, wichtige Daten vom Server regelmäßig per rsync auf einen der PCs zu spiegeln
Fun Fact: Auf Arbeit spiegele ich (zumeist nachts) Daten per rsync zwischen den Servern.
Dabei achte ich traditionsgemäß darauf, das die Jobs zeitversetzt laufen, um Platten und Netzwerk nicht unnötig zu stressen - auch wenn es heute dank schneller SSDs und 10Gbit/s-Netz wohl nicht mehr groß stören würde.
Bei mir nutzen rsync-Jobs nur 1 CPU-Kern, RAM ist vernachlässigbar.
Ich starte allerdings nur selten mehrere Jobs parallel.
Pro Festplatte würde ich wie gesagt nur 1 Job starten, bei SSDs geht vielleicht mehr. Auch hier gilt: Versuch macht kluch 
Bei solchen Kopieraktionen ist meist I/O der Flaschenhals, insbesondere bei Festplatten.
Wenn also zwei rsync-Jobs auf unterschiedlichen Platten arbeiten, kannst Du sie ruhig parallel anwerfen - genügend CPU-Kerne und RAM vorausgesetzt.
Muss eine Platte hingegen zwei parallele Jobs bedienen, wird sie womöglich zum ständigen Hin- und Herbewegen der Köpfe zwischen verschiedenen Bereichen gezwungen - und dadurch sehr langsam. Dann kann die Parallelverarbeitung sogar länger dauern als die einzelnen Jobs nacheinander.
Gewöhn Dir bitte mal an, den Output als Code zu posten - dann sieht das nicht aus wie Kraut und Rüben ...
Es wird nach gpg-Schlüsseln im Repository Packman Essentials Repository gesucht.
gpgkey=http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials/repodata/repomd.xml.key
Metadaten von Repository 'Packman Essentials Repository' abrufen ............................................................................................................................................................................................................................................[fertig]Dann würde ja ein
Coderpm --rebuilddbdas ändern. tut es aber nicht.
rpm --rebuilddb regeneriert die RPM-Datenbank aus den Headern der installierten Packages (RTFM).
Wenn es also Inkonsistenzen gibt wie z.B. ein doppelt installiertes Paket, bleiben diese auch in der neuen rpmdb erhalten.
Was sagen denn:
rpmdb --verifydb
zypper veluigi Die Pakete sind nur 1x installiert.
Dann würden sie auch nur 1x als installiert aufgelistet - und nicht 2x mit unterschiedlicher Quelle.
Mir sieht das sehr nach einem wilden Mix aus Factory und Tumbleweed aus und/oder einer beschädigten rpmdb
Wieder mal ein schönes Beispiel für das im öffentlichen Bereich weit verbreitete Prinzip "Wir sparen - koste es, was es wolle" 