1 Repositories and Priority.de
Anagnostakis Ioannis edited this page 2026-06-30 21:10:06 +03:00

EN · EL · FR · ES · IT · RU · ZH · AR · HI · PT · DE

Repositorys und Priorität

Dies ist slackers prägende Idee und das, was ihn von einem bloßen Spiegelwerkzeug abhebt: jedes Repository lebt in einem einzigen, nach Priorität geordneten Modell, und die Priorität wird niemals stillschweigend verletzt.


Die Prioritätsregel

Wenn derselbe Paketname von mehreren Repositorys angeboten wird, gewinnt das aus dem Repository mit der höchsten Priorität. Noch wichtiger:

Ein installiertes Paket wird nie stillschweigend in ein anderes Repository migriert und nie herabgestuft. Ein Kandidat wird nur aus einem Repository höherer oder gleicher Priorität vorgeschlagen. Die einzige Ausnahme ist ein ausdrückliches repo:name.

Einem Repository eine eigene, hohe Priorität zu geben sperrt somit seine Pakete: nichts aus einem niedrigeren Repository kann sie ersetzen, selbst mit einer neueren Versionsnummer nicht.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#161b22','primaryBorderColor':'#1f6feb','primaryTextColor':'#e6edf3','lineColor':'#6e7781','fontFamily':'monospace'}}}%%
flowchart TB
  I["installiertes Paket<br/>(sein build tag = seine Quelle)"] --> D{"Priorität des Kandidaten-Repos<br/>vs. die installierte Quelle"}
  D -->|höher oder gleich| U["darf aktualisieren / ersetzen"]
  D -->|niedriger| K["behalten - nie herabgestuft<br/>nie migriert"]
  PIN["repo:name"] -. "erzwingt ein Repo,<br/>überschreibt die Priorität" .-> U
  classDef grey fill:#0d1117,stroke:#6e7781,color:#8b949e;
  classDef blue fill:#0d1117,stroke:#1f6feb,color:#e6edf3;
  classDef green fill:#0d1117,stroke:#2ea043,color:#e6edf3;
  class I,PIN grey
  class D blue
  class U green
  class K grey

Wie kennt slacker die „Quelle“ eines installierten Pakets ohne Datenbank? Aus seinem build tag — dem build-Feld abzüglich der führenden Ziffern (1_SBo_SBo, 7cfcf, 1 → offiziell). Eine tag-priority-Zeile des Benutzers oder das binäre Repository höchster Priorität, das dieses Tag liefert (cf → conraid, alien → alienbob, automatisch erkannt), entscheidet, welcher Priorität es angehört.


Die Datei repos

# priority  name        url|mirror|mirror/<subpath>                          [flags]
100         slackware   mirror                                                official
200         patches     mirror/patches                                        subtree immutable
90          extras      mirror/extra                                          subtree immutable
85          testing     mirror/testing                                        subtree immutable
80          conraid     https://slackers.it/repository/slackware64-current    immutable
60          alienbob    https://slackware.nl/people/alien/sbrepos/current/x86_64
# tag-priority-Zeilen (dürfen sich eine Priorität teilen):
100         SBo         _SBo
100         local       _rtz

Das URL-Feld

Form Bedeutung
eine wörtliche URL https://, http:// oder file:// (Letzteres für einen lokalen Klon / NFS / eingehängtes Medium — drei Schrägstriche für einen absoluten Pfad)
mirror die aktive Zeile aus mirrors, unverändert — verwende sie für das offizielle Repository
mirror/<Unterpfad> der aktive Spiegel mit angehängtem Unterpfad (mirror/extra, mirror/testing, mirror/patches) — ein Unterbaum, der dem von dir gewählten Spiegel folgt

Eine URL zeigt auf die Wurzel des Repositorys, die PACKAGES.TXT enthält; bei offiziellen Spiegeln liegt MANIFEST.bz2 in einem Unterverzeichnis je Architektur, das slacker automatisch findet.

Die Flags

Flag Was es bewirkt
official Markiert das verfolgte Repository: es speist show-changelog und ist die Vorgabe für install-new. Die Platzierung erfolgt weiterhin allein nach Priorität — das offizielle Repository kann überall stehen.
immutable Jedes diesem Repository zugeordnete Paket wird von clean-system ferngehalten. Verwende es für extra/testing/patches, die du installiert hältst, statt jedes einzeln auf die Sperrliste zu setzen.
subtree Diese URL ist ein Slackware-Distributions-Unterbaum (extra, patches, testing, pasture). Deren PACKAGES.TXT listet Speicherorte relativ zur Wurzel der Distribution, daher werden Pakete und GPG-KEY von der übergeordneten (Wurzel-)URL geholt, während die Metadaten von der URL selbst stammen. Ohne es liefern diese Pakete 404 mit einem verdoppelten Pfadsegment. Die vier Unterbäume müssen dieses Flag stets tragen.
verify=... Verifizierungs-Override je Repository (siehe Security).

mirror/extra + subtree gehören zusammen. mirror/extra löst die URL auf; subtree korrigiert, wie Pakete und der Schlüssel davon geholt werden.


Pinning und Selektoren

Ein PATTERN auf der Kommandozeile kann sein:

Form Trifft auf
firefox einen exakten Paketnamen
python eine Teilzeichenkette des Namens — alle python-*
kde eine Slackware-Serie (a, ap, d, k, kde, l, n, t, x, xap, xfce, y, …) — nur diese Serie, nie Teilzeichenketten
repo:name ein Pin — erzwingt ein Repository ungeachtet der Priorität (z. B. alienbob:vlc)
@repo ein Mengenselektor — jedes Paket dieses Repositorys (install @gnome, remove @gnome)
@_tag jedes Paket mit diesem build tag (remove @_SBo)

Das @ ist erforderlich, damit ein bloßes Wort nie für ein Repository gehalten wird. Ein unbekanntes @repo/@_tag liefert einen „did you mean“-Vorschlag und listet die verfügbaren Repositorys und Tags auf.

Wenn ein Muster auf mehr als ein Paket passt, zeigen install/upgrade/reinstall/ remove eine nummerierte Liste — Eingabetaste für alle, Zahlen/Bereiche wie 1 3 5 oder 2-4, n zum Abbrechen.

Es gibt keinen Platzhalter * für die Auswahl auf der Kommandozeile. Ein nicht in Anführungszeichen gesetztes * wird von deiner Shell zu den Dateinamen des aktuellen Verzeichnisses expandiert, bevor slacker läuft (slacker sieht das * nie und liest dein Verzeichnis nie); ergibt das eine Flut von Nicht-Paket-Argumenten, erkennt slacker das und verweigert den Befehl, ohne etwas zu ändern. Setze ein wörtliches Muster in Anführungszeichen oder verwende @repo für ein ganzes Repository. (Die Blacklist ist der einzige Ort, an dem Muster tatsächlich Globs/Regex sind.)


Repositorys über die CLI verwalten

slacker add-repo  85 ktown https://slackware.nl/people/alien/ktown/current/x86_64
slacker add-repo  90 extras mirror/extra subtree immutable
slacker del-repo  ktown
slacker pri-repo  95 extras          # die Priorität eines bestehenden Repos neu einstellen
slacker add-tag   100 SBo _SBo
slacker del-tag   _SBo
slacker list-repos          # Priorität, verify, Flags, Anzahl installierter

add-repo validiert die Zeile und holt und prüft (vets) das Repository nach Bestätigung (siehe Security).

pri-repo PRIORITY NAME ändert die Priorität eines Repositorys, das du bereits hast. Es prüft, dass NAME ein aktives Repository ist (schlägt bei einem Tippfehler die nächste Übereinstimmung vor), und verweigert eine PRIORITY, die ein anderes Repository bereits hält, indem es den Konflikt benennt, damit du einen anderen Wert wählst — Prioritäten müssen verschieden bleiben. Nur die Priorität dieser Zeile wird neu geschrieben; URL und Flags bleiben genau, wie sie waren.