2027a/auroscope

Watch

Fork 0

[Decision D3] Séquencer les upgrades officiels et AUR sans partial upgrade #4

New issue

Closed

opened 2026-08-30 20:42:55 +00:00 by hephaistos · 7 comments

hephaistos commented

2026-08-30 20:42:55 +00:00

Owner

MODE: DECISION

Statut

Proposé. Ticket ouvert jusqu’à ta réponse puis ton go explicite.

Question

Comment maintenir un upgrade officiel complet tout en permettant de différer certaines recettes AUR et en inspectant avant toute mutation de paquets ?

Contraintes

Arch ne supporte pas les partial upgrades des dépôts officiels.
Les paquets AUR doivent pouvoir être différés.
La spécification demande une identification/revue avant modification du système.
Le plan de dépendances AUR peut changer après l’upgrade officiel.

Options

A — Upgrade Paru combiné avec exclusions injectées

Pour : une expérience proche d’une transaction unique.
Contre : plan machine faible, refresh avant revue, risques de partial upgrade si des paquets officiels sont exclus.

B — Prérevue AUR, phase officielle complète, puis replanification AUR

Interroger/planifier et revoir provisoirement les candidats AUR avant mutation;
exécuter paru -Syu --repo comme transaction officielle complète;
replanifier AUR sur l’état courant;
toute identité/origine/fermeture de dépendance changée retourne à l’humain;
exécuter les AUR approuvés et ignorer la fermeture des paquets détenus.

Pour : pas de partial upgrade officiel; autorité humaine conservée; dérive visible.
Contre : deux plans AUR et deux phases visibles; un AUR peut être temporairement incompatible après la phase officielle.

C — Upgrader officiel d’abord, revoir AUR ensuite

Pour : simple.
Contre : viole la lecture stricte « identifier avant de changer le système ».

Recommandation

Option B. Les conséquences de dépendances du premier plan sont marquées provisoires; le second plan est exécutable seulement s’il correspond aux décisions.

Réponse attendue

Choisis A/B/C ou amende le séquencement. Aucun ADR/clôture avant ton go.

Documentation

Protocole automatique de décision

Ce ticket reste en discussion et n’autorise aucune implémentation.
Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket.
Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement :

GO DECISION

Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket.
GO DECISION n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket MODE: EXECUTION.

MODE: DECISION ## Statut **Proposé.** Ticket ouvert jusqu’à ta réponse puis ton **go explicite**. ## Question Comment maintenir un upgrade officiel complet tout en permettant de différer certaines recettes AUR et en inspectant avant toute mutation de paquets ? ## Contraintes - Arch ne supporte pas les partial upgrades des dépôts officiels. - Les paquets AUR doivent pouvoir être différés. - La spécification demande une identification/revue avant modification du système. - Le plan de dépendances AUR peut changer après l’upgrade officiel. ## Options ### A — Upgrade Paru combiné avec exclusions injectées **Pour :** une expérience proche d’une transaction unique. **Contre :** plan machine faible, refresh avant revue, risques de partial upgrade si des paquets officiels sont exclus. ### B — Prérevue AUR, phase officielle complète, puis replanification AUR 1. Interroger/planifier et revoir provisoirement les candidats AUR avant mutation; 2. exécuter `paru -Syu --repo` comme transaction officielle complète; 3. replanifier AUR sur l’état courant; 4. toute identité/origine/fermeture de dépendance changée retourne à l’humain; 5. exécuter les AUR approuvés et ignorer la fermeture des paquets détenus. **Pour :** pas de partial upgrade officiel; autorité humaine conservée; dérive visible. **Contre :** deux plans AUR et deux phases visibles; un AUR peut être temporairement incompatible après la phase officielle. ### C — Upgrader officiel d’abord, revoir AUR ensuite **Pour :** simple. **Contre :** viole la lecture stricte « identifier avant de changer le système ». ## Recommandation **Option B.** Les conséquences de dépendances du premier plan sont marquées provisoires; le second plan est exécutable seulement s’il correspond aux décisions. ## Réponse attendue Choisis A/B/C ou amende le séquencement. Aucun ADR/clôture avant ton **go**. ## Documentation - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md - https://git.2027a.net/2027a/auroscope/pulls/1 ## Protocole automatique de décision - Ce ticket reste en discussion et n’autorise aucune implémentation. - Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket. - Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement : ```text GO DECISION ``` - Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket. - `GO DECISION` n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket `MODE: EXECUTION`.

hephaistos added the

labels

2026-08-30 20:45:46 +00:00

mathieu commented

2026-08-30 20:56:02 +00:00

Owner

Je ne comprends pas le problème avec C ? C'est ma préférence mais je voudrais comprendre quel problème tu envisages avec cette solution très simple?

hephaistos commented

2026-08-30 23:19:34 +00:00

Author

Owner

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement GO DECISION dans un commentaire distinct.

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement `GO DECISION` dans un commentaire distinct.

hephaistos commented

2026-08-30 23:22:08 +00:00

Author

Owner

Tu as raison : C n’a pas de problème technique intrinsèque. Au contraire, c’est le séquencement le plus simple pour éviter un partial upgrade :

afficher et faire revoir la transaction des dépôts officiels;
exécuter l’upgrade officiel complet (paru -Syu --repo), sans exclusion de paquet officiel;
recalculer les candidats et dépendances AUR sur le nouvel état;
faire revoir ce plan AUR, puis n’appliquer que les recettes approuvées.

Mon objection venait uniquement d’une lecture très stricte de la contrainte « identifier avant de changer le système » : j’avais compris qu’il fallait identifier aussi les AUR avant la moindre mutation officielle. Mais cette prérevue AUR est provisoire et peut être invalidée par l’upgrade officiel; elle ajoute donc du travail sans apporter une garantie forte.

Si la contrainte signifie plutôt « chaque phase doit être inspectée avant sa propre mutation », C la respecte : revue officielle avant l’upgrade officiel, puis revue AUR avant l’upgrade AUR. Le seul état intermédiaire possible est qu’un paquet AUR installé soit temporairement incompatible après l’upgrade officiel; B ne supprime pas réellement ce risque, puisque son premier plan AUR reste provisoire.

Recommandation actuelle : option C, précisée comme ci-dessus. Elle est plus simple que B, conserve l’autorité humaine avant chaque mutation et ne crée pas de partial upgrade officiel. Il faudra reformuler la contrainte pour expliciter que la revue est par phase, pas globale avant toute mutation.

Ce commentaire propose donc C; il ne l’enregistre pas comme décision acceptée.

Tu as raison : **C n’a pas de problème technique intrinsèque**. Au contraire, c’est le séquencement le plus simple pour éviter un partial upgrade : 1. afficher et faire revoir la transaction des dépôts officiels; 2. exécuter l’upgrade officiel complet (`paru -Syu --repo`), sans exclusion de paquet officiel; 3. recalculer les candidats et dépendances AUR sur le nouvel état; 4. faire revoir ce plan AUR, puis n’appliquer que les recettes approuvées. Mon objection venait uniquement d’une lecture très stricte de la contrainte « identifier avant de changer le système » : j’avais compris qu’il fallait identifier **aussi les AUR** avant la moindre mutation officielle. Mais cette prérevue AUR est provisoire et peut être invalidée par l’upgrade officiel; elle ajoute donc du travail sans apporter une garantie forte. Si la contrainte signifie plutôt « chaque phase doit être inspectée avant sa propre mutation », C la respecte : revue officielle avant l’upgrade officiel, puis revue AUR avant l’upgrade AUR. Le seul état intermédiaire possible est qu’un paquet AUR installé soit temporairement incompatible après l’upgrade officiel; B ne supprime pas réellement ce risque, puisque son premier plan AUR reste provisoire. **Recommandation actuelle : option C, précisée comme ci-dessus.** Elle est plus simple que B, conserve l’autorité humaine avant chaque mutation et ne crée pas de partial upgrade officiel. Il faudra reformuler la contrainte pour expliciter que la revue est par phase, pas globale avant toute mutation. Ce commentaire propose donc C; il ne l’enregistre pas comme décision acceptée.

mathieu commented

2026-08-30 23:29:14 +00:00

Owner

GO DECISION

Pour la revue officielle, inutile d'ajouter quoi que ce soit par dessus paru/Pacman. On Audit uniquement AUR

GO DECISION Pour la revue officielle, inutile d'ajouter quoi que ce soit par dessus paru/Pacman. On Audit uniquement AUR

hephaistos commented

2026-08-30 23:36:36 +00:00

Author

Owner

D’accord. Ça simplifie encore la frontière : Auroscope n’ajoute aucune couche de revue à la transaction officielle; Paru/Pacman reste seul responsable de l’upgrade complet des dépôts officiels. L’audit et l’approbation portent uniquement sur AUR.

Recommandation actuelle : option C, avec ce séquencement précis :

exécuter l’upgrade officiel complet avec le comportement natif de Paru/Pacman (paru -Syu --repo ou équivalent), sans exclusion de paquet officiel et sans pré-audit Auroscope;
une fois le système officiel à jour, recalculer les candidats AUR et leur fermeture de dépendances sur cet état réel;
auditer les recettes AUR, présenter les changements pertinents et demander l’approbation humaine;
construire/installer uniquement les AUR approuvés; les autres AUR peuvent être différés.

Le risque accepté est qu’un AUR déjà installé puisse être temporairement incompatible entre les étapes 1 et 4. Faire une prérevue AUR avant l’upgrade officiel ne supprimerait pas ce risque et produirait un plan potentiellement périmé.

Ta formulation GO DECISION est accompagnée d’un amendement dans le même commentaire; selon le protocole déterministe, je la traite donc comme une poursuite de discussion, pas comme le signal exact d’acceptation. La proposition concrète à accepter est désormais C + audit exclusivement AUR, telle que décrite ci-dessus.

D’accord. Ça simplifie encore la frontière : **Auroscope n’ajoute aucune couche de revue à la transaction officielle**; Paru/Pacman reste seul responsable de l’upgrade complet des dépôts officiels. L’audit et l’approbation portent uniquement sur AUR. **Recommandation actuelle : option C, avec ce séquencement précis :** 1. exécuter l’upgrade officiel complet avec le comportement natif de Paru/Pacman (`paru -Syu --repo` ou équivalent), sans exclusion de paquet officiel et sans pré-audit Auroscope; 2. une fois le système officiel à jour, recalculer les candidats AUR et leur fermeture de dépendances sur cet état réel; 3. auditer les recettes AUR, présenter les changements pertinents et demander l’approbation humaine; 4. construire/installer uniquement les AUR approuvés; les autres AUR peuvent être différés. Le risque accepté est qu’un AUR déjà installé puisse être temporairement incompatible entre les étapes 1 et 4. Faire une prérevue AUR avant l’upgrade officiel ne supprimerait pas ce risque et produirait un plan potentiellement périmé. Ta formulation `GO DECISION` est accompagnée d’un amendement dans le même commentaire; selon le protocole déterministe, je la traite donc comme une poursuite de discussion, pas comme le signal exact d’acceptation. La proposition concrète à accepter est désormais **C + audit exclusivement AUR**, telle que décrite ci-dessus.

mathieu commented

2026-08-30 23:47:43 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

2026-08-30 23:51:32 +00:00

hephaistos referenced this issue

2026-08-30 23:56:18 +00:00

Decision D3: sequence official upgrade before AUR review #16

hephaistos commented

2026-08-30 23:57:04 +00:00

Author

Owner

Décision D3 consignée et vérifiée.

ADR : ADR-0004 — Complete official upgrade before AUR review
Commit signé : 0fea99db83342872eeb94c4a9505dbd745730dba
PR de décision vers la branche de design : #16

La spécification et le registre de propositions reflètent désormais le séquencement accepté : transaction officielle complète et native d'abord, sans audit AURoscope; planification, audit et décisions AUR ensuite sur l'état réellement mis à jour. Aucun code de production ni plan d'implémentation n'a été ajouté.

Décision D3 consignée et vérifiée. - ADR : [`ADR-0004 — Complete official upgrade before AUR review`](https://git.2027a.net/2027a/auroscope/src/commit/0fea99db83342872eeb94c4a9505dbd745730dba/docs/decisions/0004-official-upgrade-before-aur-review.md) - Commit signé : [`0fea99db83342872eeb94c4a9505dbd745730dba`](https://git.2027a.net/2027a/auroscope/commit/0fea99db83342872eeb94c4a9505dbd745730dba) - PR de décision vers la branche de design : [#16](https://git.2027a.net/2027a/auroscope/pulls/16) La spécification et le registre de propositions reflètent désormais le séquencement accepté : transaction officielle complète et native d'abord, sans audit AURoscope; planification, audit et décisions AUR ensuite sur l'état réellement mis à jour. Aucun code de production ni plan d'implémentation n'a été ajouté.

hephaistos closed this issue

2026-08-30 23:57:21 +00:00