Gato/Pena
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

docs: documentation fonctionnelle, technique et installation

Browse Source
This commit is contained in:
Gato
2026-07-05 10:58:29 +02:00
parent 61fb56fa14
commit 64c53f412d
12 changed files with 1452 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/3-installation/3.1-Installation.md
+89
View File
@@ -0,0 +1,89 @@
# Installation (Linux générique / Fedora)
Cette page décrit l'installation de **Pena-tauri** sur une distribution Linux classique
(mutable), où l'on peut installer des paquets système avec le gestionnaire de la distribution.
- Pour un système **immuable** (Bazzite, Fedora Silverblue/Kinoite, openSUSE MicroOS…), voir
[Installation sur Bazzite OS](3.2-Installation-Bazzite.md).
- Pour le détail des commandes de compilation, voir [Build](3.3-Build.md).
## 1. Installer les prérequis
### Rust et Tauri CLI
```bash
# Rust (toolchain stable)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
# Tauri CLI v2
cargo install tauri-cli --version "^2"
```
### Dépendances système
**Fedora / RHEL :**
```bash
sudo dnf install webkit2gtk4.1-devel \
openssl-devel curl wget file libappindicator-gtk3-devel librsvg2-devel
sudo dnf group install "C Development Tools and Libraries"
```
**Debian / Ubuntu :**
```bash
sudo apt update
sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file \
libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev
```
## 2. Récupérer les sources
```bash
git clone <url-du-depot> Pena
cd Pena/Pena-tauri
```
## 3. Compiler et installer
### Lancer directement (développement)
```bash
cargo tauri dev
```
### Construire une release
```bash
cargo tauri build
```
L'exécutable est produit dans `src-tauri/target/release/`. Pour l'installer à l'échelle du
système, copiez-le dans un dossier du `PATH` :
```bash
sudo install -Dm755 src-tauri/target/release/pena-taury /usr/local/bin/pena
```
Vous pouvez ensuite lancer l'application avec `pena`.
> **Nom du binaire** : le binaire s'appelle `pena-taury` (nom du paquet Cargo). Renommez-le à
> votre convenance lors de l'installation, comme ci-dessus (`pena`).
## 4. (Optionnel) Raccourci d'application
Pour faire apparaître Pena dans le menu des applications, créez un fichier `.desktop` :
```bash
cat > ~/.local/share/applications/pena.desktop <<'EOF'
[Desktop Entry]
Type=Application
Name=Pena
Comment=Lecteur Markdown
Exec=/usr/local/bin/pena
Terminal=false
Categories=Utility;Office;
EOF
```
## Voir aussi
- [Build et compilation](3.3-Build.md)
- [Installation sur Bazzite OS](3.2-Installation-Bazzite.md)
- [Vue d'ensemble](../1-fonctionnel/1.1-Vue-d-ensemble.md)
docs/3-installation/3.2-Installation-Bazzite.md
+253
View File
@@ -0,0 +1,253 @@
# Installation sur Bazzite OS
[Bazzite](https://bazzite.gg/) est une distribution **immuable** basée sur Fedora Atomic
(rpm-ostree). Le système de fichiers racine est en lecture seule : on **n'installe pas** de
paquets de développement (`webkit2gtk-devel`, compilateurs…) directement sur l'hôte comme on
le ferait sur une Fedora classique.
Cette contrainte vaut aussi pour les autres systèmes atomiques (Fedora Silverblue, Kinoite,
Universal Blue, openSUSE MicroOS…).
La méthode recommandée est le **Flatpak** : on construit **une seule fois** un fichier
`.flatpak` (le « bundle »), on l'héberge (par ex. sur un dépôt Gitea), puis on l'installe sur
n'importe quelle machine **en une commande**, sans rien compiler ni installer de dépendance
sur l'hôte.
| Vous voulez… | Allez à… |
|---|---|
| **Installer Pena** depuis un `.flatpak` déjà construit (récupéré sur Gitea) | [1. Méthode simple](#1-méthode-simple--installer-le-paquet-pré-construit) |
| **Produire** le fichier `.flatpak` (une fois, sur une machine de build) | [2. Compiler](#2-compiler-le-binaire-une-fois) puis [3. Construire le bundle](#3-construire-le-paquet-flatpak-une-fois) |
| **Développer / itérer** sur le code sans empaqueter | [4. Alternative développeur (distrobox)](#4-alternative-développeur--lancer-via-distrobox) |
> Bazzite fournit **`flatpak`** (avec le dépôt Flathub), **`distrobox`** et **`podman`**
> préinstallés. Aucune surcouche rpm-ostree (`rpm-ostree install`) n'est nécessaire.
---
## 1. Méthode simple — installer le paquet pré-construit
C'est le scénario du quotidien : le fichier `pena.flatpak` a déjà été construit (voir
sections 2 et 3) et déposé sur votre Gitea. Sur la machine cible, il suffit de le récupérer et
de l'installer.
### 1.1 — Installer
```bash
# Récupérer le bundle depuis Gitea (adaptez l'URL à votre dépôt)
curl -L -o pena.flatpak \
https://git.goutailler-olivier.com/<utilisateur>/<depot>/raw/branch/main/pena.flatpak
# Installer pour l'utilisateur courant (aucun droit root nécessaire)
flatpak install --user pena.flatpak
```
> Le runtime `org.gnome.Platform` (qui fournit WebKitGTK) est téléchargé automatiquement
> depuis Flathub lors de l'installation s'il n'est pas déjà présent. C'est la seule dépendance,
> et elle est gérée par Flatpak — rien à compiler ni à installer sur l'hôte.
### 1.2 — Lancer
```bash
flatpak run com.pena.app
```
Pena apparaît aussi dans le menu des applications de Bazzite.
### 1.3 — Mettre à jour / désinstaller
```bash
# Mettre à jour : récupérer le nouveau bundle puis réinstaller par-dessus
flatpak install --user --reinstall pena.flatpak
# Désinstaller
flatpak uninstall com.pena.app
```
### 1.4 — (Optionnel) Installation en une ligne
Vous pouvez déposer à côté du bundle, sur Gitea, un script `install.sh` qui automatise le
téléchargement et l'installation :
```bash
#!/usr/bin/env bash
set -euo pipefail
URL="https://git.goutailler-olivier.com/<utilisateur>/<depot>/raw/branch/main/pena.flatpak"
TMP="$(mktemp --suffix=.flatpak)"
curl -L -o "$TMP" "$URL"
flatpak install --user -y "$TMP"
rm -f "$TMP"
echo "Pena installé. Lancez-le avec : flatpak run com.pena.app"
```
L'installation se résume alors à :
```bash
curl -L https://git.goutailler-olivier.com/<utilisateur>/<depot>/raw/branch/main/install.sh | bash
```
---
## 2. Compiler le binaire (une fois)
Cette étape et la suivante se font **sur une machine de build** (la vôtre, dans un container).
Le résultat est un fichier `pena.flatpak` que vous n'aurez plus qu'à héberger.
Pena se compile dans un container Ubuntu via **distrobox**, pour ne rien installer sur l'hôte
immuable. WebKitGTK et le compilateur restent dans le container.
```bash
# 1. Créer et entrer dans un container Ubuntu
distrobox create --name pena-build --image ubuntu:24.04
distrobox enter pena-build
# 2. (dans le container) installer les dépendances de build
sudo apt update
sudo apt install -y \
libwebkit2gtk-4.1-dev build-essential curl wget file \
libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source "$HOME/.cargo/env"
cargo install tauri-cli --version "^2"
# 3. (dans le container) compiler
cd ~/Pena/Pena-tauri # adaptez le chemin vers les sources
cargo tauri build
```
Le binaire est produit dans `src-tauri/target/release/pena-taury`. Vous pouvez ensuite
quitter le container (`exit`) : la suite (section 3) se fait sur l'hôte, où `flatpak` est
disponible. Comme `$HOME` est partagé entre l'hôte et le container, le binaire compilé est
accessible des deux côtés.
---
## 3. Construire le paquet `.flatpak` (une fois)
À partir du binaire compilé, on produit le fichier unique `pena.flatpak`.
### 3.1 — Outillage Flatpak (sur l'hôte)
```bash
flatpak install -y flathub org.gnome.Platform//47 org.gnome.Sdk//47 org.flatpak.Builder
```
### 3.2 — Fichiers d'empaquetage
Depuis la racine `Pena-tauri/`, créez deux fichiers.
**`com.pena.app.desktop`** :
```ini
[Desktop Entry]
Type=Application
Name=Pena
Comment=Lecteur Markdown
Exec=pena
Icon=com.pena.app
Terminal=false
Categories=Utility;Office;
```
**`com.pena.app.yml`** (manifeste Flatpak) :
```yaml
id: com.pena.app
runtime: org.gnome.Platform
runtime-version: '47'
sdk: org.gnome.Sdk
command: pena
finish-args:
- --share=ipc
- --socket=wayland
- --socket=fallback-x11
- --device=dri
# Accès en lecture aux fichiers Markdown de l'utilisateur
- --filesystem=home:ro
modules:
- name: pena
buildsystem: simple
build-commands:
- install -Dm755 pena-taury /app/bin/pena
- install -Dm644 com.pena.app.desktop /app/share/applications/com.pena.app.desktop
- install -Dm644 icon.png /app/share/icons/hicolor/512x512/apps/com.pena.app.png
sources:
- type: file
path: src-tauri/target/release/pena-taury
- type: file
path: com.pena.app.desktop
- type: file
path: src-tauri/icons/icon.png
```
> L'identifiant `com.pena.app` correspond au champ `identifier` de
> `src-tauri/tauri.conf.json`. Le runtime `org.gnome.Platform` embarque WebKitGTK : l'app
> fonctionnera sans aucune dépendance installée sur la machine cible.
### 3.3 — Construire le bundle
Depuis `Pena-tauri/` :
```bash
# 1. Construire l'app dans un dépôt OSTree local (dossier "repo")
flatpak run org.flatpak.Builder --force-clean --repo=repo \
--install-deps-from=flathub build-dir com.pena.app.yml
# 2. Exporter en UN SEUL fichier .flatpak
flatpak build-bundle repo pena.flatpak com.pena.app \
--runtime-repo=https://flathub.org/repo/flathub.flatpakrepo
```
Vous obtenez **`pena.flatpak`** : c'est ce fichier unique, autoportant, que vous installez
partout (section 1). L'option `--runtime-repo` y inscrit la référence vers Flathub, pour que
le runtime soit récupéré automatiquement à l'installation.
### 3.4 — Héberger sur Gitea
Déposez `pena.flatpak` sur votre dépôt Gitea, soit :
- en l'ajoutant au dépôt (`git add pena.flatpak`) — simple, mais alourdit l'historique ;
- **de préférence**, en l'attachant à une **release** Gitea (onglet *Releases* → *New Release*
→ joindre le binaire). L'URL de téléchargement direct est alors stable et n'encombre pas le
dépôt.
Adaptez ensuite l'URL utilisée à la [section 1.1](#11--installer).
---
## 4. Alternative développeur — lancer via distrobox
Si vous **développez** sur Pena et n'avez pas besoin d'un paquet installable, vous pouvez
exécuter l'application directement depuis le container, sans passer par Flatpak.
```bash
# Lancement direct (la fenêtre s'affiche sur le bureau de l'hôte)
distrobox enter pena-build -- bash -lc 'cd ~/Pena/Pena-tauri && cargo tauri dev'
```
Pour exposer le binaire compilé à l'hôte comme une commande :
```bash
# Depuis le container, après "cargo tauri build"
distrobox-export --bin ~/Pena/Pena-tauri/src-tauri/target/release/pena-taury \
--export-path ~/.local/bin
```
Le binaire devient lançable depuis l'hôte (`~/.local/bin` doit être dans le `PATH`). Cette
voie est pratique pour itérer, mais le Flatpak (sections 1–3) reste la méthode recommandée
pour une **installation** propre et reproductible.
---
## Note — AppImage
Une autre forme de « fichier unique à exécuter » est l'**AppImage** : un binaire autoportant
qui se lance sans installation (`chmod +x Pena.AppImage && ./Pena.AppImage`). Tauri sait en
produire, mais cela nécessite d'activer le bundler (`bundle.active: true` dans
`tauri.conf.json`, cible `appimage`) et l'outillage associé. Le **bundle Flatpak** décrit
ci-dessus est privilégié ici car il s'intègre au menu, se met à jour proprement et gère
automatiquement ses dépendances via Flathub.
## Voir aussi
- [Release et distribution](3.4-Release-et-distribution.md) — pourquoi le Flatpak, portabilité et trade-offs des formats
- [Build et compilation](3.3-Build.md)
- [Installation (Linux générique / Fedora)](3.1-Installation.md)
- [Architecture](../2-technique/2.1-Architecture.md)
docs/3-installation/3.3-Build.md
+110
View File
@@ -0,0 +1,110 @@
# Build et compilation
Cette page décrit comment compiler **Pena-tauri** depuis les sources, en développement comme
en production. Pour une installation sur un système immuable (Bazzite, Silverblue, etc.),
voir plutôt [Installation sur Bazzite OS](3.2-Installation-Bazzite.md).
## Prérequis
| Outil | Détail |
|---|---|
| **Rust** | Toolchain stable, via [rustup](https://rustup.rs/) (édition 2021). |
| **Tauri CLI v2** | `cargo install tauri-cli --version "^2"` (fournit `cargo tauri`). |
| **Dépendances système** | WebKitGTK et libs associées (voir ci-dessous selon la distribution). |
Le frontend n'a **aucune dépendance Node** : c'est du JS vanilla servi statiquement depuis
`src/`. Il n'y a donc pas de `npm install` à faire pour `Pena-tauri`.
### Dépendances système Linux
**Fedora / RHEL :**
```bash
sudo dnf install webkit2gtk4.1-devel \
openssl-devel curl wget file libappindicator-gtk3-devel librsvg2-devel
sudo dnf group install "C Development Tools and Libraries"
```
**Debian / Ubuntu :**
```bash
sudo apt update
sudo apt install libwebkit2gtk-4.1-dev build-essential curl wget file \
libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev
```
> Sur une distribution immuable (Bazzite, Fedora Silverblue, Kinoite…), n'installez pas ces
> paquets sur l'hôte : utilisez un container ou un Flatpak. Voir
> [Installation sur Bazzite OS](3.2-Installation-Bazzite.md).
## Lancer en développement
Depuis `Pena-tauri/` :
```bash
cargo tauri dev
```
- Le frontend est servi directement depuis `src/` (fichiers statiques, sans bundler).
- La compilation Rust est lancée automatiquement et l'application s'ouvre.
- Toute modification du Rust déclenche une recompilation.
## Construire une release
Depuis `Pena-tauri/` :
```bash
cargo tauri build
```
L'exécutable est produit dans :
```
src-tauri/target/release/
```
### À propos du bundling
Dans `src-tauri/tauri.conf.json`, le bundling est **désactivé** :
```json
"bundle": { "active": false, "targets": "all", "icon": [] }
```
`cargo tauri build` produit donc l'**exécutable natif** (dans `target/release/`), mais ne
génère pas de paquets `.deb`, `.rpm` ou `.AppImage`. Pour activer la génération de ces
paquets, passer `bundle.active` à `true` et renseigner les icônes.
## Compiler le backend seul (sans Tauri CLI)
Pour de la compilation / des tests bas niveau, depuis `src-tauri/` :
```bash
cargo build # compilation debug
cargo build --release # compilation optimisée
cargo test # tests unitaires
cargo clippy -- -D warnings # lint (zéro warning toléré)
```
## Qualité et couverture
Le dépôt `Pena-tauri` impose un hook `pre-commit` qui bloque le commit si :
- **Clippy** remonte le moindre warning (`-D warnings`) ;
- la **couverture de lignes** est inférieure à **60 %** (via `cargo-llvm-cov`).
Installer l'outil de couverture :
```bash
cargo install cargo-llvm-cov
cargo llvm-cov --summary-only
```
## Récapitulatif des commandes
| But | Commande (depuis `Pena-tauri/`) |
|---|---|
| Développement | `cargo tauri dev` |
| Release (exécutable) | `cargo tauri build` |
| Compiler le backend | `cargo build --release` (depuis `src-tauri/`) |
| Tests | `cargo test` (depuis `src-tauri/`) |
| Lint | `cargo clippy -- -D warnings` |
| Couverture | `cargo llvm-cov --summary-only` |
## Voir aussi
- [Release et distribution](3.4-Release-et-distribution.md) — portabilité du binaire et création d'un paquet Flatpak
- [Installation (Linux générique)](3.1-Installation.md)
- [Installation sur Bazzite OS](3.2-Installation-Bazzite.md)
- [Architecture](../2-technique/2.1-Architecture.md)
docs/3-installation/3.4-Release-et-distribution.md
+277
View File
@@ -0,0 +1,277 @@
# Release et distribution
Cette page explique **comment fonctionne une release de Pena** : ce que produit réellement la
compilation, **si un binaire compilé sur une distribution Linux est utilisable sur n'importe
quelle autre**, et les différentes façons de **distribuer** l'application — avec un focus sur le
**paquet Flatpak** et ses avantages/inconvénients.
- Pour les commandes de compilation pures, voir [Build et compilation](3.3-Build.md).
- Pour la procédure pas-à-pas d'installation Flatpak sur système immuable, voir
[Installation sur Bazzite OS](3.2-Installation-Bazzite.md).
---
## 1. Que produit une release ?
`cargo tauri build` (depuis `Pena-tauri/`) produit un **exécutable natif** :
```
src-tauri/target/release/pena-taury
```
C'est un binaire ELF compilé pour l'architecture de la machine de build (typiquement
`x86_64-linux-gnu`). Le frontend (HTML/CSS/JS de `src/`) y est **embarqué** dans le binaire :
il n'y a pas de fichiers web à distribuer à côté.
> Dans `tauri.conf.json`, `bundle.active` vaut `false` : `cargo tauri build` ne génère donc
> **pas** de `.deb`/`.rpm`/`.AppImage` automatiquement. Il produit l'exécutable seul. La
> génération de paquets est traitée plus bas (section 4).
### Ce que le binaire contient — et ce qu'il ne contient pas
| Embarqué dans le binaire | **Pas** embarqué (fourni par le système) |
|---|---|
| Code Rust de Pena (commandes Tauri) | **glibc** (bibliothèque C) |
| Frontend (HTML/CSS/JS) | **WebKitGTK** (le moteur de rendu de la fenêtre) |
| `comrak` + `syntect` (rendu Markdown) | **GTK 3/4**, GLib, Cairo, Pango… |
| Plugins Tauri liés statiquement | Pilotes graphiques, serveur d'affichage (X11/Wayland) |
C'est ce tableau qui répond à la question de la portabilité.
---
## 2. Un binaire compilé sur Linux marche-t-il sur **n'importe quelle** distribution ?
**Réponse courte : non, pas de façon fiable.** Un binaire « brut » (le `pena-taury` produit
ci-dessus) n'est **pas universel**. Il dépend de bibliothèques présentes sur le système cible,
et il ne tournera ailleurs que si ces bibliothèques sont **présentes et compatibles**.
Trois raisons concrètes :
### 2.1 — Le lien dynamique avec WebKitGTK
C'est la contrainte la plus dure pour une app Tauri. Le binaire est lié à
**`libwebkit2gtk-4.1`**. Sur la machine cible, il faut :
- que WebKitGTK soit **installé** ;
- que ce soit la **bonne version d'ABI** : `webkit2gtk-4.0` et `webkit2gtk-4.1` ont des
*sonames* différents et **ne sont pas interchangeables**. Un binaire lié à `4.1` ne démarrera
pas sur une machine qui n'a que `4.0`, et inversement.
Sur une distribution récente, WebKitGTK 4.1 est généralement disponible ; sur une
distribution plus ancienne ou minimaliste, il peut manquer.
### 2.2 — La version de la glibc
Les binaires liés à la glibc sont **compatibles vers l'avant, pas vers l'arrière** :
- un binaire compilé sur une **vieille** glibc tourne sur une machine ayant une glibc **plus
récente** ✅ ;
- un binaire compilé sur une glibc **récente** échoue sur une machine ayant une glibc **plus
ancienne** ❌, avec une erreur du type `version 'GLIBC_2.38' not found`.
**Conséquence pratique :** pour maximiser la portabilité d'un binaire brut, compilez-le sur la
distribution la **plus ancienne** que vous comptez supporter (par ex. dans un container
Ubuntu 22.04), pas sur la plus récente.
### 2.3 — Les autres bibliothèques système
GTK, GLib, Cairo, Pango, librsvg, libappindicator… doivent aussi être présentes. Sur un poste
de bureau classique elles le sont presque toujours (ce sont des dépendances de l'environnement
de bureau), mais sur un serveur, un système minimal ou immuable, ce n'est pas garanti.
### Récapitulatif portabilité
| Cible | Le binaire brut marche-t-il ? |
|---|---|
| Même distribution / version que la machine de build | ✅ Oui |
| Distribution différente mais récente, avec `webkit2gtk-4.1` et glibc ≥ celle du build | ✅ Généralement |
| Distribution avec une glibc **plus ancienne** que le build | ❌ Non (`GLIBC_x.y not found`) |
| Distribution qui n'a que `webkit2gtk-4.0` | ❌ Non (soname incompatible) |
| Système immuable (Bazzite, Silverblue…) | ❌ Pas directement — voir Flatpak |
| Architecture différente (ARM vs x86_64) | ❌ Non — il faut recompiler pour l'archi |
**Conclusion :** « compilé sur Linux » ne veut pas dire « marche sur tout Linux ». Pour une
distribution **réellement universelle**, il faut un format qui **embarque ses dépendances** :
c'est le rôle du **Flatpak** (recommandé ici) ou de l'**AppImage**.
---
## 3. Les formats de distribution possibles
| Format | Dépendances | Portabilité | Intégration bureau | Mise à jour |
|---|---|---|---|---|
| **Binaire brut** | Fournies par l'hôte | Faible (voir §2) | Manuelle (`.desktop`) | Manuelle |
| **`.deb` / `.rpm`** | Déclarées, résolues par le gestionnaire de paquets | Bonne **sur la famille visée** (Debian *ou* Fedora) | Automatique | Via le gestionnaire |
| **AppImage** | **Embarquées** dans un fichier exécutable | Bonne (un seul fichier portable) | Partielle | Manuelle (re-télécharger) |
| **Flatpak** | **Embarquées** via un *runtime* partagé (Flathub) | **Excellente** (toute distro avec `flatpak`) | Complète (menu, icône) | `flatpak update` |
Pour Pena, le format **recommandé est le Flatpak** : il résout d'un coup les trois problèmes du
§2 (WebKitGTK, glibc, libs système) en fournissant un **runtime** complet et identique partout.
---
## 4. Créer un paquet Flatpak
Le Flatpak rend l'application **vraiment portable** : le moteur WebKitGTK et toutes les
bibliothèques système viennent du **runtime `org.gnome.Platform`** (téléchargé depuis Flathub),
pas de l'hôte. Le même `pena.flatpak` s'installe alors sur n'importe quelle distribution dotée
de `flatpak`, immuable ou non.
> La procédure complète (installation côté machine cible, hébergement sur Gitea, alternative
> développeur) est détaillée dans [Installation sur Bazzite OS](3.2-Installation-Bazzite.md).
> On résume ici les étapes de **production** du paquet.
### 4.1 — Principe en trois temps
```
[ cargo tauri build ] → binaire natif pena-taury
│
▼
[ manifeste Flatpak ] → build dans un dépôt OSTree local "repo/"
│
▼
[ flatpak build-bundle ] → fichier unique pena.flatpak
```
### 4.2 — Outillage (une fois)
```bash
flatpak install -y flathub org.gnome.Platform//47 org.gnome.Sdk//47 org.flatpak.Builder
```
### 4.3 — Le manifeste
Le manifeste décrit l'identifiant de l'app, le runtime qui fournit les dépendances, et comment
installer le binaire dans le sandbox. Depuis `Pena-tauri/`, créer **`com.pena.app.yml`** :
```yaml
id: com.pena.app # = identifier de tauri.conf.json
runtime: org.gnome.Platform # fournit WebKitGTK + GTK + glibc du runtime
runtime-version: '47'
sdk: org.gnome.Sdk
command: pena
finish-args:
- --share=ipc
- --socket=wayland
- --socket=fallback-x11
- --device=dri
- --filesystem=home:ro # lecture des fichiers Markdown de l'utilisateur
modules:
- name: pena
buildsystem: simple
build-commands:
- install -Dm755 pena-taury /app/bin/pena
- install -Dm644 com.pena.app.desktop /app/share/applications/com.pena.app.desktop
- install -Dm644 icon.png /app/share/icons/hicolor/512x512/apps/com.pena.app.png
sources:
- type: file
path: src-tauri/target/release/pena-taury
- type: file
path: com.pena.app.desktop
- type: file
path: src-tauri/icons/icon.png
```
Et le fichier d'intégration au menu **`com.pena.app.desktop`** :
```ini
[Desktop Entry]
Type=Application
Name=Pena
Comment=Lecteur Markdown
Exec=pena
Icon=com.pena.app
Terminal=false
Categories=Utility;Office;
```
> Point clé sur la portabilité : `finish-args` définit le **sandbox**. Pena n'a besoin que de
> l'affichage (Wayland/X11), du GPU (`dri`) et d'un **accès en lecture seule** au `home`
> (`--filesystem=home:ro`) pour ouvrir les fichiers `.md`. C'est volontairement minimal.
### 4.4 — Construire le bundle
Depuis `Pena-tauri/`, après un `cargo tauri build` réussi :
```bash
# 1. Construire dans un dépôt OSTree local "repo/"
flatpak run org.flatpak.Builder --force-clean --repo=repo \
--install-deps-from=flathub build-dir com.pena.app.yml
# 2. Exporter en UN SEUL fichier .flatpak autoportant
flatpak build-bundle repo pena.flatpak com.pena.app \
--runtime-repo=https://flathub.org/repo/flathub.flatpakrepo
```
On obtient **`pena.flatpak`** : un fichier unique, installable partout par
`flatpak install --user pena.flatpak`. L'option `--runtime-repo` y inscrit la référence
Flathub, pour que le runtime soit récupéré automatiquement à l'installation s'il manque.
---
## 5. Flatpak : avantages et inconvénients
### Avantages
- **Portabilité réelle.** Le runtime fournit WebKitGTK, GTK et une glibc cohérente : les trois
blocages du §2 disparaissent. Le même fichier marche sur Fedora, Ubuntu, Arch, Bazzite,
Silverblue… sans recompiler.
- **Aucune dépendance à installer sur l'hôte.** Idéal pour les systèmes **immuables** (Bazzite,
Silverblue) où l'on ne peut pas faire `dnf install webkit2gtk-devel`.
- **Installation sans root** (`--user`).
- **Sandbox.** L'app n'a accès qu'à ce que `finish-args` autorise (ici : affichage + `home` en
lecture seule). Surface d'attaque réduite.
- **Intégration de bureau** automatique (entrée de menu, icône) et **mises à jour** par
`flatpak update`.
- **Reproductible.** Le runtime versionné (`//47`) garantit le même socle partout.
### Inconvénients
- **Taille.** Le **runtime** `org.gnome.Platform` pèse plusieurs centaines de Mo. Il n'est
téléchargé qu'une fois et partagé entre toutes les apps Flatpak, mais c'est lourd pour une app
aussi simple que Pena si c'est le seul Flatpak de la machine.
- **Premier lancement / première install** plus longs (téléchargement du runtime).
- **Le sandbox demande de la réflexion.** Tout accès fichier hors `home:ro` doit être déclaré
explicitement ; un oubli se traduit par une fonctionnalité qui « ne voit pas » les fichiers.
- **Dépendance à Flathub** pour récupérer le runtime (réseau requis à l'installation).
- **Outillage de build** supplémentaire (`flatpak-builder`, SDK) par rapport à un simple
`cargo tauri build`.
### Quand préférer une autre option
| Situation | Format conseillé |
|---|---|
| Diffusion large, multi-distributions, systèmes immuables | **Flatpak** |
| Un seul fichier à exécuter sans rien installer | **AppImage** (`bundle.active: true`, cible `appimage`) |
| Cible une seule famille (que Debian, ou que Fedora) avec gestion par paquets | **`.deb`** / **`.rpm`** |
| Usage perso sur sa propre machine, ou itération de dev | **Binaire brut** / `cargo tauri dev` |
> **AppImage** est l'autre format « un seul fichier ». Tauri sait en produire (activer le
> bundler dans `tauri.conf.json`), mais le **Flatpak** est privilégié ici pour son intégration
> au menu, ses mises à jour propres et la gestion automatique des dépendances via Flathub.
---
## 6. Liste de contrôle d'une release
1. Vérifier la version dans `src-tauri/tauri.conf.json` (`"version"`).
2. Compiler dans un environnement à **glibc ancienne** si l'on distribue un binaire brut
(container Ubuntu 22.04), sinon directement.
3. `cargo tauri build` → vérifier `src-tauri/target/release/pena-taury`.
4. Construire le `pena.flatpak` (section 4).
5. Tester l'install sur une machine **vierge** : `flatpak install --user pena.flatpak` puis
`flatpak run com.pena.app`.
6. Héberger le `.flatpak` sur **une release Gitea** (URL stable, n'alourdit pas le dépôt) —
voir [3.2 §3.4](3.2-Installation-Bazzite.md).
---
## Voir aussi
- [Build et compilation](3.3-Build.md)
- [Installation sur Bazzite OS](3.2-Installation-Bazzite.md) — installation et hébergement du Flatpak
- [Installation (Linux générique / Fedora)](3.1-Installation.md)
- [Architecture](../2-technique/2.1-Architecture.md)