tuxnix So ganz hab ich es aber auch nicht verstanden was du da vorhast.
Du willst nur selektiv einige Pakete vom Upgrade zurückhalten. Nun, du kennst dich aus, nicht immer müssen Teil-Upgrades zur Katastrophe führen.
Nein, daß hast du falsch verstanden. Es sollen deinitiv keine Pakete zurückgehalten werden, sondern der ganze Update-Vorgang findet (erstmal) nicht statt.
Beispiel:
Angenommen ich wäre ein Gnome-Nutzer und beim letzten großen Update(48.x zu 49.x) - wie viele - erstmal auf die Schnauze gefallen weil sich eben wesentliche Dinge geändert haben. Ich habe übersehen daß ein "großes" Update ansteht und konnte kein "Backup" mehr machen.
Damit mir sowas nicht nochmal passiert nutze ich den pacman PRE-Hook. Das Paket mutter ist bei Gnome ein wesentlicher Bestandteil, es reicht wenn ich dieses Paket "überwache".
Ich mache ganz normal mein: pacman -Syu
Der Hook sieht nun so aus:
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = mutter
[Action]
Description = check for unwanted updates...
When = PreTransaction
Exec = /usr/local/bin/pacman_prevent_update_for
NeedsTargets
PreTransaction-Hooks laufen ja nun nach dem DB-Sync(-y) aber vor dem Updatepozess(-u) bei einem pacman -Syu.
Wenn in der Liste der anstehenden Updates nun das Paket "mutter" dabei wäre, dann übergibt der Hook den Paketnamen(Target) an das Skript bei Ecec=
In diesem Script mache ich nun folgendes (alles teilweise nur Pseudo-Code):
Erhalte die Liste der Target-Pakete vom Hook (hier nur mutter)
case "$package" in
"mutter")
# Ich will mutter nur auf Major-Upgrades prüfen
act_on_major_update $package
;;
esac
Die Funktion act_on_major_update stellt nun erstmal die Version des lokal(aktuell) installierten mutter-Paketes fest und die des neuen Paketes($package). Dafür trennt es eben die Versionsnummer in seine Bestandteile auf.
Angenommen meine aktuell Version ist: 48.5-2 (das war die letzte 48er). Die Version die zum Update anstehen würde wäre die 49.0-1. "48" und "49" sind hier die Major-Version, "5-2" und "0.1" sind jeweils Minor-Version und archrelease(-1).
Die Funktion kommt nun zu dem Ergebnis:
[[ new_major -gt current_major ]] -> True (Oh, Oh, böses Update!)
und veranlaßt das Skript am Ende zu einem: exit 1
Dadurch wird das gesamte: pacman -Syu abgebrochen, aber zu einem Zeitpunkt wenn noch keine Veränderungen am System passiert sind.
Das Skript gibt zudem noch einen passenden Hinweis aus wie:
Pacman Update ABGEBROCHEN im Pre-Hook blabla
Grund:
- Es steht ein Major-Update für Gnome an (mutter 48.5-2 -> 49.0-1)
Bitte Vorkehrungen treffen (Backup, Test mit neuem User, Snapshots, ...)
Danach das Update erneut starten mit:
NOPREVENTHOOK=1 pacman -Syu
Nun kann ich meine Vorbereitigungen treffen und dann das Update erneut durchführen.
NOPREVENTHOOK=1 pacman -Syu
Danach habe ich dann "Ruhe" bis Gnome 49 eben auf 50 geht.
Wie gesagt, ich schere mich nicht um die weiteren, "normalen" Updates von mutter, solange es eben kein Major-Update ist.
Entsprechende andere Kriterien kann es im Skript halt auch geben (minor_zero z.B.). Und halt auch das ein Paket gar kein Kriterium erfüllen muß damit das ganze Update erstmal gestoppt/nicht ausgeführt wird. Das ist dann eine Entscheidung des Users.
Ich hoffe, daß wird etwas deutlicher jetzt. Keine Gefahr für teilweise Updates, es wird nichts "ignoriert".
Als Targets für so einen Hool bieten sich z.B. auch (SQL)Datenbanken an(postges,mariadb), da eben gerade Major-Updates eine Migration der Datenbank/Tabellenstruktur vornehmen bzw. erfordern. Da will man ggf. vorher ein Backup machen.
Normalerweise "sieht" man/ich in der Liste der zu updateten Pakete schon die "Kandidaten", der Hook ist eher dafür gedacht als "Letzte Tankstelle vor der Wüste".
Da ich noch schwanke zwischen Shell-Skript oder Ruby-Skript kann noch noch keinen vollständigen Code liefern (Ruby ist für mich einfacher, gerade bei dem Versions-Aufgesplittere, mal schauen)
Uups, schau mal auf die Uhr...
Zu den anderen Dingen schreibe ich morgen noch was.
//Edit:
tuxnix Ich mache mir Notizen konfiguriere den Rechner und schreibe im gleichen Rutsch die Anleitung dazu. Kannst du dir ja mal bei Gelegenheit ansehen wenn du magst
Vorweg: Ich habe von Audio-Verarbeitung null Schimmer, ich war/bin immer froh wenn irgendwas aus den Lautsprechern rauskommt.
Einzig; man sollte auf jedenfall pipewire statt pulseaudio verwenden, das hat erheblich zur Stabilität meines Systems beigetragen(list man auch immer mal im .org Forum). Aber das hast du ja in deiner Anleitung.
Du kennst ja sicher die .org-Wiki Seite zu Professional audio?
Dort (und ein paarmal habe ich es gelesen) wird Jack als Soundserver empfohlen, scheinbar auch wegen Low-Latency und RT-Fähigkeiten. Kann aber sein das daß schon durch pipewire-jack "abgedeckt" ist.
Auch ob's ein Realtime-Kernel sein muß oder nicht wird dort beleuchtet. Habe ich keine Ahnung von.
Ansonsten sehe ich nichts, wo mir ad hoc ein Fehler auffällt.
Viel Erfolg!