mathieuandClaude Opus 5
d0ebecc233
Le manifeste de la 0.5.0, deja publiee, s'est mis a pointer une archive
introuvable — l'installation echouait sur ynh_setup_source, sans que le
symptome designe la cause.
Le remplacement global des URL avait reecrit amd64.url, c'est-a-dire
precisement le champ que la documentation ecrite le meme jour designait comme
« a ne jamais changer a la main », puisque publier.sh le regenere a chaque
publication.
⚠ L'erreur de conception est plus large : le placeholder avait sa place dans la
COPIE publique, pas dans le depot de travail, qui sert au deploiement reel et
doit rester operationnel. Anonymiser un depot qui sert encore, c'est le casser.
Ce qui reste, et qui vaut : depot_code commande toujours toutes les URL
derivees, et le garde-fou refuse toujours de publier avec une URL en
example.org — il ne se declenche simplement plus ici, puisqu'il sert a la copie
publique.
sha256 inchange : seule l'URL avait bouge, le manifeste retrouve exactement son
etat de publication.
--- L'installation ne demande plus qui a acces
init_main_permission quitte [install] au profit de
resources.permissions.main.allowed = "all_users". Verifie dans le coeur
YunoHost (src/utils/resources.py) :
init_allowed = infos["allowed"] or self.get_setting(f"init_{perm}_permission") or []
allowed L'EMPORTE sur la question. La garder l'aurait donc posee pour rien, en
laissant croire que la reponse comptait.
⚠ Ce n'est pas un reglage de confort : visitors casserait deux invariants du
code. L'application n'a aucune authentification propre — elle fait confiance a
YNH_USER parce que SSOwat l'ecrase a chaque requete, exactement comme elle
n'ecoute que sur 127.0.0.1 — et toute personne autorisee peut SUPPRIMER
n'importe quel livre du catalogue commun, sans role ni lecture seule.
⚠ Pas de protected = true, delibere : restreindre a un groupe dedie reste
legitime, et c'est l'affaire de l'administrateur. C'est l'elargissement qui est
un contresens, pas le reglage.
⚠ allowed n'agit qu'a la CREATION de la permission (if perm not in
existing_perms) : une montee de version ne realigne rien. Un commentaire de
manifeste n'atteignant aucun administrateur, l'avertissement vit dans
doc/DESCRIPTION.md (page d'installation) et doc/ADMIN.md (interface
d'administration) — les deux seuls fichiers du paquet que YunoHost lit lui-meme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Paquet YunoHost pour MaBibli
Paquet d'installation de MaBibli, application de gestion de bibliothèque personnelle (catalogue, prêts, scan ISBN).
Ce dépôt ne contient aucun code C#. Il porte uniquement de quoi installer sur YunoHost une archive déjà compilée : le manifeste, les configurations nginx et systemd, les scripts d'installation, et les scripts de publication.
📖 Toute la documentation est dans le dépôt du code
Elle a été regroupée dans le README de mabibli,
qui est le point d'entrée unique du projet : contenu et points de conception du paquet,
publication d'une version, mise en production pas à pas, montée de version, retour arrière,
désinstallation, et contraintes permanentes.
Il n'y a qu'une seule chaîne de publication et un seul projet : deux jeux de documentation finissaient par diverger, et l'on ne savait plus lequel faisait autorité.
Ne restent ici que les deux fichiers que YunoHost lit lui-même et qui doivent donc vivre à côté du manifeste :
doc/DESCRIPTION.md— présentation affichée dans le catalogue d'applicationsdoc/ADMIN.md— authentification, emplacement des données, sauvegarde ; affichée dans l'interface d'administration une fois l'application installée
Publier une nouvelle version
# Depuis ce dépôt, avec le dépôt du code à côté (../mabibli)
./build/publier.sh
Le détail — ce que le script vérifie, ce qui reste manuel, et la marche à suivre côté serveur —
est dans le README de mabibli.