bug: les utilisateurs installes en .rpm ne peuvent pas se mettre a jour (latest.json ne sert que le .deb) #320

Open
opened 2026-07-28 01:29:38 +00:00 by maximus · 0 comments
Owner

src-tauri/tauri.conf.json bundle trois cibles : ["nsis", "deb", "rpm"]. release.yml construit et publie bien les trois. Mais l'entree linux-x86_64 de latest.json est construite uniquement a partir du .deb :

.forgejo/workflows/release.yml:104   for f in release-assets/*.deb.sig; do
.forgejo/workflows/release.yml:107   for f in release-assets/*.deb; do
.forgejo/workflows/release.yml:122   '. + {"linux-x86_64": {"signature": $sig, "url": $url}}'

latest.json n'a pas de notion de format de paquet : il y a une entree par cible, et Linux pointe sur le .deb.

Consequence

Un utilisateur installe depuis le .rpm qui lance une verification de mise a jour telecharge des octets .deb. Cote tauri-plugin-updater, le format d'installeur est resolu depuis le marqueur __TAURI_BUNDLE_TYPE grave dans l'artefact : le binaire rpm resout Installer::Rpm, qui verifie la signature magique du payload avant de le passer au gestionnaire de paquets, et rejette les octets deb.

Donc : les utilisateurs rpm recoivent un echec de mise a jour, pas une mise a jour silencieusement cassee — mais ils n'ont aucun chemin de mise a jour automatique, alors qu'on leur livre un artefact. La mise a jour automatique etant une fonctionnalite Base+, ce sont des utilisateurs payants.

Incoherence connexe

Le texte des notes de release annonce le mauvais format :

.forgejo/workflows/release.yml:158   **Linux** : Telechargez le fichier `.deb` ou `.AppImage` ci-dessous.

Aucun AppImage n'est construit. Le .rpm, lui, existe et n'est pas mentionne.

Pistes

  • Le plus simple : ne plus bundler le .rpm s'il n'a pas d'utilisateur connu — un artefact sans chemin de mise a jour est un piege.
  • Sinon : servir un latest.json distinct par format, ou basculer Linux sur l'AppImage (le seul format que tauri-plugin-updater sait reellement extraire lui-meme, via install_appimage — c'est aussi le seul chemin qui exercerait tar, cf. #315).
  • Dans tous les cas, corriger le texte des notes de release.

Releve pendant #315 / #312.

`src-tauri/tauri.conf.json` bundle **trois** cibles : `["nsis", "deb", "rpm"]`. `release.yml` construit et publie bien les trois. Mais l'entree `linux-x86_64` de `latest.json` est construite **uniquement a partir du `.deb`** : ``` .forgejo/workflows/release.yml:104 for f in release-assets/*.deb.sig; do .forgejo/workflows/release.yml:107 for f in release-assets/*.deb; do .forgejo/workflows/release.yml:122 '. + {"linux-x86_64": {"signature": $sig, "url": $url}}' ``` `latest.json` n'a pas de notion de format de paquet : il y a **une** entree par cible, et Linux pointe sur le `.deb`. ## Consequence Un utilisateur installe depuis le `.rpm` qui lance une verification de mise a jour telecharge des octets `.deb`. Cote `tauri-plugin-updater`, le format d'installeur est resolu depuis le marqueur `__TAURI_BUNDLE_TYPE` grave dans l'artefact : le binaire rpm resout `Installer::Rpm`, qui verifie la signature magique du payload avant de le passer au gestionnaire de paquets, et **rejette** les octets deb. Donc : les utilisateurs rpm recoivent un echec de mise a jour, pas une mise a jour silencieusement cassee — mais ils n'ont **aucun** chemin de mise a jour automatique, alors qu'on leur livre un artefact. La mise a jour automatique etant une fonctionnalite Base+, ce sont des utilisateurs payants. ## Incoherence connexe Le texte des notes de release annonce le mauvais format : ``` .forgejo/workflows/release.yml:158 **Linux** : Telechargez le fichier `.deb` ou `.AppImage` ci-dessous. ``` Aucun AppImage n'est construit. Le `.rpm`, lui, existe et n'est pas mentionne. ## Pistes - Le plus simple : **ne plus bundler le `.rpm`** s'il n'a pas d'utilisateur connu — un artefact sans chemin de mise a jour est un piege. - Sinon : servir un `latest.json` distinct par format, ou basculer Linux sur l'AppImage (le seul format que `tauri-plugin-updater` sait reellement extraire lui-meme, via `install_appimage` — c'est aussi le seul chemin qui exercerait `tar`, cf. #315). - Dans tous les cas, corriger le texte des notes de release. Releve pendant #315 / #312.
maximus added the
status:ready
type:bug
source:analyste
labels 2026-07-28 01:29:38 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: maximus/Simpl-Resultat#320
No description provided.