Comment les paramètres dépendent les uns des autres

Deux champs de la base de connaissances contiennent de la logique au lieu de données, et ils répondent à deux questions différentes. Les confondre est l’erreur que cette page a pour but d’éviter.

available détermine si un paramètre est ou non une ligne que l’utilisateur peut atteindre. default-value détermine la valeur qui lui est attribuée – non pas une seule fois, mais chaque fois que change quelque chose que nomme son expression.

Une option qui ne peut pas être choisie

Un paramètre dont l’expression available est fausse n’est pas affiché. La boîte de dialogue est construite à partir des paramètres disponibles, si bien que la ligne n’y figure tout simplement pas, et la consigne au-dessus de la liste reçoit une remarque indiquant combien de paramètres manquent et où se renseigner à leur sujet.

Il ne disparaît pas sans laisser de trace. Le texte d’aide de la boîte de dialogue liste chaque paramètre indisponible de cette boîte de dialogue sous un titre qui lui est propre, avec sa description complète et une ligne supplémentaire, dans laquelle l’expression est la propre condition available de ce paramètre, sans les accents graves :

=== Condition of availability: === <the expression>

Perdre sa disponibilité ne signifie pas en soi perdre sa valeur. Le moteur ne désactive un paramètre indisponible qu’à un seul endroit précis : lorsque l’utilisateur valide une boîte de dialogue, parmi les lignes de cette boîte de dialogue, pour un paramètre dont l’utilisateur vient de supprimer la disponibilité par sa propre modification dans cette boîte de dialogue. Un paramètre qui devient indisponible à cause d’une action de l’utilisateur dans une autre boîte de dialogue conserve la valeur qu’il avait auparavant, et il ne figure plus nulle part sous forme de ligne, si bien que plus rien, à cet endroit, n’interagira avec lui.

C’est à cela que sert le second champ, et c’est pourquoi les deux sont si souvent utilisés ensemble.

Une option qui en suit une autre

Un default-value peut être une expression, et une telle expression n’est pas une valeur de repli. Chaque fois qu’un paramètre qu’elle nomme change, le moteur la réévalue et applique le résultat – en remplaçant une valeur que l’utilisateur a choisie à la main, si c’est ce que dit désormais l’expression. Le moteur ne garde aucune trace de qui a défini une valeur, si bien qu’il n’a rien devant quoi s’effacer. Seul un default-value littéral se comporte comme une valeur de départ et n’est ensuite plus touché.

Le résultat se propage : son application peut modifier un paramètre que nomme une troisième expression, laquelle est évaluée à son tour. Aucune partie du moteur ne connaît un paramètre en particulier ; toute la chaîne se trouve dans les données.

La boîte de dialogue des systèmes de fichiers, dans son intégralité

ZFS a besoin de DKMS, et DKMS ne peut pas compiler sur un noyau qui a dépassé ce que prend en charge OpenZFS. Ditana associe donc ZFS au noyau à support à long terme, et il faut les deux champs pour y parvenir :

- name="zfs-filesystem" \
  available="`install-standard-lts-kernel`" \
  default-value="`install-standard-lts-kernel AND NOT profile-quick`" {
    // ...
  }

La ligne available est la barrière. Choisir un autre noyau ne fait pas passer ZFS sur le noyau LTS et ne laisse pas non plus ZFS fonctionner sur un noyau pour lequel il ne peut pas être compilé : la ligne ZFS disparaît de la boîte de dialogue des systèmes de fichiers, et l’association tient parce que l’état non associé n’est pas un état que l’utilisateur peut sélectionner.

Pour ce paramètre, l’aide indique, dans la boîte de dialogue des systèmes de fichiers d’une installation qui n’utilise pas le noyau à support à long terme :

=== Condition of availability: === install-standard-lts-kernel

C’est la ligne default-value qui rend la barrière effective depuis une autre boîte de dialogue. Le noyau se choisit dans la boîte de dialogue Kernel Selection, où ZFS n’est pas une ligne, si bien que la règle qui désactive un paramètre indisponible ne l’atteint jamais. C’est le fait de nommer la même condition dans default-value qui désactive ZFS – et c’est pourquoi quarante-cinq paramètres de la base de connaissances comportent une expression dans les deux champs. L’un ne remplace pas l’autre.

- name="btrfs-filesystem" \
  default-value="`profile-quick OR NOT install-standard-lts-kernel`" {
    arch-packages "btrfs-progs" "compsize"
  }

Btrfs est la valeur par défaut de la boîte de dialogue des systèmes de fichiers dès que le profil Quick Installation est choisi ou que le noyau LTS n’est pas sélectionné. Les deux expressions sont les moitiés complémentaires d’une même condition, si bien qu’à tout moment, exactement un système de fichiers est choisi. Un utilisateur qui abandonne le noyau LTS pour un autre constate donc, en revenant à la boîte de dialogue des systèmes de fichiers, que la ligne ZFS a disparu, que Btrfs est choisi et que la remarque au-dessus de la liste renvoie à l’aide, où la condition qui a retiré ZFS est affichée en toutes lettres.

Le noyau LTS est la valeur par défaut au départ, si bien que dans une configuration standard, rien de tout cela n’apparaît : ZFS est proposé, et le choisir n’entraîne aucun changement de noyau, puisque le noyau est déjà le bon.

Ce que cela signifie pour une contribution

Les deux champs répondent à deux questions, et une relation a généralement besoin d’une réponse aux deux. L’option a-t-elle seulement un sens sous cette condition ? C’est available, et il retire la ligne. L’option doit-elle suivre cette condition ? C’est default-value, et il modifie la valeur, depuis n’importe quelle boîte de dialogue. Une barrière dont la condition se décide dans la même boîte de dialogue peut se contenter de available seul ; une barrière dont la condition se trouve ailleurs ne le peut pas, et c’est le cas le plus courant.