@Walter_vdV
Zu deiner 1. Frage: Wie qui es schon schrieb. Wobei als Ergänzung: "den 1. unkommentierten" -> auf dem das Paket in der angeforderten Version auch verfügbar ist. Das greift dann, wenn mehrere Spiegelserver aktiviert sind. Mirror A steht als präferierter Mirror aktiv vorne in der Liste aber kann das Paket nicht liefern, dann werden nacheinander in eben der Reihenfolge der mirrorlist die anderen abgefragt. Bis entweder zum Erfolg oder zum Abbruch mit Fehlermeldung. Dieses nacheinander Abarbeiten wird nur bei einer realen Installation bzw. Download des/der Pakete gemacht, pacman -Sp gibt immer die URL des 1. aktiven Mirrors aus der mirrorlist zurück da ja nicht geprüft wird ob das Paket tatsächlich runterladbar wäre.
Mit -Sp kann man zum einen schnell prüfen welchen Mirror man denn präferiert verwendet und es ist v.a. nützlich um Download-Listen zu erstellen wenn am eigenen Gerät die Internetverbindung schlecht oder eingeschränkt(Volumen,Drossel) ist.
Beispiel:
pacman -Sy
pacman -Sup > update.list
An einem anderen Rechner/Stelle kann diese Liste nun z.B. an wget verfüttert werden, was die Pakete holen würde. Diese nun wieder zum Originalgerät transportiert und in den Pacman-Cache kopiert erspart bei einem pacman -Su (Upgrade ohne Datenbankaktualisierung (-y)) das Runterladen dieser Pakete.
Zu 2.:
Du selbst kommst eigentlich mit den Schlüsseln nicht direkt in Kontakt, daß was oben "händisch" durchgespielt wurde macht pacman intern automagisch. Trotzdem schafft obige "Übung" und mein Sermon evtl. etwas Hintergrundwissen (was ja bekanntlich nie schadet und die Synapsen jung hält <g>). Mein Wissen zu pacman ist allerdings eine Zeitlang her, wobei das Prinzip sich wohl nicht grundlegend geändert hat. Und eigentlich jeder vergleichbare Paketmanager so arbeitet.
Wenn ein Paket mit pacman installiert wird passiert folgendes:
a) Die Version wird anhand der aktuellen Datenbank (pacman -Sy) ermittelt.
b) Das Paket wird vom ersten aktiven Spiegelserver der es liefern kann runtergeladen und final in /var/cache/pacman/pkg abgelegt.
c) Die Signatur des Paketes wird temporär ebenfalls vom Spiegelserver geholt. Ein Paketersteller signiert mit !seinem! privaten, geheimen Schlüssel sein gebautes Paket und lädt dieses und die dazugehörende Signaturdatei auf das zentrale Archlinux-Repository, an diesem gleichen sich die Spiegelserver ab.
d) pacman prüft nun, ob Paket _und_ Signatur zusammenpassen (was oben händisch gemacht wurde), gleichzeitig noch die SHA256-Prüfsumme die in der Datenbank hinterlegt ist (diese Prüfsummen-Prüfung führte z.B. zu deiner ursprünglichen Problemfehlermeldung).
e) ist nun der entscheidende Punkt in diesem Signatur/"Vertrauen"-Modell: eine letztendliche Installation findet nur statt wenn der verwendete Schlüssel des (eigentlich ordnungsgemäß signierten) Paketes zum einen in !deinem! lokalen pacman-Schlüsselring ist und dort gültig ist und eine Mindeststufe von Vertrauen hat. Nur dann wird ein Paket auch installiert.
Der Schlüsselring wird vom Paket archlinux-keyring verwaltet, was das Hinzufügen, Ändern, Widerrufen und Vertrauensstufe erteilen umfaßt. Darin sind die öffentlichen Schlüssel der Entwickler und (AUR)-TrustedUser, also derjenigen die kompilierte bzw. Binärpakete erstellen (core,extra,community,testing).
Somit wird weitgehend ausgeschlossen daß z.B. auf einem Spiegelserver ein manipuliertes Paket liegt welches sogar ornungsgemäß eine Signatur hat (korrekt ein Paket "signieren" kann jeder mit einem privaten Schlüssel). Aber nur wenn sich der öffentliche Teil des Schlüssels auch gültig in deinem Schlüsselring befindet, dann wird das Paket auch akzeptiert.
Oder ein ehemaliger Entwickler möchte aus Frust/Langeweile eine manipulierte Version "seines" Paketes verteilen, daß wird dann scheitern wenn über den aktuellen Stand des archlinux-keyring-Paketes eben dessen Schlüssel als widerrufen/ungültig, ohne Vertrauen, in deinem Keyring markiert ist.
Das archlinux-keyring-Paket bzw. der "Mechanismus des Vertrauens" ist so geregelt: nur eine Handvoll von Entwicklern (die mit sog. Master-Schlüsseln) dürfen Schlüssel dort hinzufügen oder ändern. Somit ist auch ein weitgehender Amoklauf von einzelnen Entwicklern/Paketbauern nahezu ausgeschlossen.
So, daß bringt vielliecht etwas Klarheit (oder neue, konkrete Fragen <g>)... Übrigens halte ich pacman für den noch immer am durchdachtesten Paketmanager den ich kenne, vielleicht fehlt die zillionste Option für "obskure Szenarien" <g> , aber im Brot-und-Butter-Bereich und auch für Sonderfälle gibt es für nahezu alles eine Möglichkeit.