Repositories and Priority.fr

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

Dépôts et priorité

C'est l'idée fondatrice de slacker, et ce qui le distingue d'un simple outil de miroir : chaque dépôt vit dans un unique modèle ordonné par priorité, et la priorité n'est jamais violée en silence.

---

La règle de priorité

Quand le même nom de paquet est proposé par plusieurs dépôts, c'est celui du dépôt de priorité la plus élevée qui l'emporte. Plus important encore :

Un paquet installé n'est jamais migré en silence vers un autre dépôt, et jamais rétrogradé. Un candidat n'est proposé que depuis un dépôt de priorité supérieure ou égale. La seule exception est un repo:name explicite.

Ainsi, donner à un dépôt une priorité élevée et distincte verrouille ses paquets : rien venant d'un dépôt inférieur ne peut les remplacer, même avec un numéro de version plus récent.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#161b22','primaryBorderColor':'#1f6feb','primaryTextColor':'#e6edf3','lineColor':'#6e7781','fontFamily':'monospace'}}}%%
flowchart TB
  I["paquet installé<br/>(son build tag = sa source)"] --> D{"priorité du dépôt candidat<br/>vs la source installée"}
  D -->|supérieure ou égale| U["peut mettre à niveau / remplacer"]
  D -->|inférieure| K["conservé - jamais rétrogradé<br/>jamais migré"]
  PIN["repo:name"] -. "force un dépôt,<br/>passant outre la priorité" .-> 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

Loading

Comment slacker connaît-il la « source » d'un paquet installé sans base de données ? Par son build tag — le champ build moins les chiffres de tête (1_SBo → _SBo, 7cf → cf, 1 → officiel). Une ligne tag-priority de l'utilisateur, ou le dépôt binaire de plus haute priorité qui livre cette étiquette (cf → conraid, alien → alienbob, détecté automatiquement), décide de la priorité à laquelle il appartient.

---

Le fichier 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
# lignes tag-priority (peuvent partager une priorité) :
100         SBo         _SBo
100         local       _rtz

Le champ URL

Forme	Signification
une URL littérale	https://, http://, ou file:// (ce dernier pour un clone local / NFS / média monté — trois barres obliques pour un chemin absolu)
mirror	la ligne active de mirrors, telle quelle — à utiliser pour le dépôt officiel
mirror/<sous-chemin>	le miroir actif avec un sous-chemin ajouté (mirror/extra, mirror/testing, mirror/patches) — un sous-arbre qui suit le miroir que vous avez choisi

Une URL pointe vers la racine du dépôt contenant PACKAGES.TXT ; pour les miroirs officiels, MANIFEST.bz2 se trouve dans un sous-répertoire par architecture que slacker localise automatiquement.

Les flags

Flag	Ce qu'il fait
official	Marque le dépôt suivi : il alimente show-changelog et sert de défaut à install-new. Le placement reste uniquement déterminé par la priorité — le dépôt officiel peut se trouver n'importe où.
immutable	Tout paquet attribué à ce dépôt est tenu à l'écart de clean-system. À utiliser pour extra/testing/patches que vous gardez installés, au lieu de les blacklister un par un.
subtree	Cette URL est un sous-arbre de distribution Slackware (extra, patches, testing, pasture). Leur PACKAGES.TXT liste les emplacements relatifs à la racine de la distribution ; les paquets et GPG-KEY sont donc récupérés depuis l'URL parente (racine) tandis que les métadonnées viennent de l'URL elle-même. Sans ce flag, ces paquets renvoient 404 avec un segment de chemin dédoublé. Les quatre sous-arbres doivent toujours porter ce flag.
verify=...	Surcharge de vérification par dépôt (voir Security).

mirror/extra + subtree vont de pair. mirror/extra résout l'URL ; subtree corrige la façon dont les paquets et la clé en sont récupérés.

---

Épinglage (pinning) et sélecteurs

Un PATTERN en ligne de commande peut être :

Forme	Correspond à
firefox	un nom de paquet exact
python	une sous-chaîne de nom — tous les python-*
kde	une série Slackware (a, ap, d, k, kde, l, n, t, x, xap, xfce, y, …) — cette série seulement, jamais des sous-chaînes
repo:name	un pin — force un dépôt indépendamment de la priorité (p. ex. alienbob:vlc)
@repo	un sélecteur d'ensemble — tous les paquets de ce dépôt (install @gnome, remove @gnome)
@_tag	tous les paquets portant cette étiquette de build (remove @_SBo)

Le @ est obligatoire, de sorte qu'un mot nu n'est jamais pris pour un dépôt. Un @repo/@_tag inconnu donne une suggestion « did you mean » et liste les dépôts et étiquettes disponibles. Inversement, un mot nu qui nomme un dépôt et non un paquet (download fontforge ponce — un : oublié) n'obtient pas le nom de paquet le plus proche : slacker dit qu'il s'agit d'un dépôt et donne les deux formes, ponce:<package> et @ponce.

Ne mélangez pas un nom de paquet nu avec @repo dans une même commande. install vlc @alienbob se lit « vlc et tous les paquets d'alienbob », ce qui n'est presque jamais voulu — slacker le refuse et indique alienbob:vlc. Chaque forme seule reste inchangée : @repo prend toujours un dépôt entier, plusieurs @repo se combinent, et un pin repo:name peut côtoyer @repo puisqu'il nomme déjà son dépôt et ne peut pas s'étendre.

Un argument sans correspondance annule toute la commande. install, upgrade, reinstall, remove et download agissent sur tous leurs arguments ou sur aucun : si l'un ne correspond à rien, rien n'est fait et l'argument fautif est nommé. -y ne contourne pas cela.

Quand un pattern correspond à plus d'un paquet, install/upgrade/reinstall/ remove affichent une liste numérotée — Entrée pour tout, des numéros/plages comme 1 3 5 ou 2-4, n pour annuler.

Il n'existe aucun joker * pour la sélection en ligne de commande. Un * non protégé est étendu par votre shell en noms de fichiers du répertoire courant avant que slacker ne s'exécute (slacker ne voit jamais le * et ne lit jamais votre répertoire) ; si cela produit un flot d'arguments non-paquets, slacker le reconnaît et refuse la commande, sans rien changer. Protégez un pattern littéral par des guillemets, ou utilisez @repo pour tout un dépôt. (La Blacklist est le seul endroit où les patterns sont des globs/regex.)

---

Gérer les dépôts depuis le CLI

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          # réajuster la priorité d'un dépôt existant
slacker add-tag   100 SBo _SBo
slacker del-tag   _SBo
slacker list-repos          # priorité, verify, flags, nombre d'installés

Ces commandes prennent des noms de dépôt nus, sans @. Le @ n'existe que là où un mot nu serait sinon un nom de paquet ; install-new, clean-cache, vet-repo, trust-repo, distrust-repo, del-repo et pri-repo n'acceptent que des dépôts, il n'y a donc rien à distinguer. install-new @ponce est refusé avec une suggestion du nom nu.

add-repo valide la ligne et, après confirmation, récupère et contrôle (vets) le dépôt (voir Security).

pri-repo PRIORITY NAME change la priorité d'un dépôt que vous avez déjà. Il vérifie que NAME est un dépôt actif (suggérant la correspondance la plus proche en cas de faute de frappe) et refuse une PRIORITY qu'un autre dépôt détient déjà, en nommant le conflit pour que vous choisissiez une autre valeur — les priorités doivent rester distinctes. Seule la priorité de cette ligne est réécrite ; l'URL et les flags restent exactement tels quels.