Suivi du packaging des nœuds v2

Suite au sujet Stratégie de packaging pour Duniter v2, je lance ce tableau en mode wiki pour suivre l’avancée du packaging des noeuds v2, en particulier Duniter.

Architectures processeur

  • amd64 / x86_64 (wiki)
  • armv8 / aarch64 (wiki)
  • [autre ?]

Légende des tableaux

  • CI : automatisation
      • = manuel
      • = script externe
      • = intégré à la CI Gitlab et présent sur les pages de release
  • archi : architectures disponibles
      • = aucune
      • = au moins une
      • = toutes

Duniter v2s

C’est notre véritable porte d’entrée, il faut mettre des efforts là dessus et considérer toute suggestion raisonnable.

paquet CI archi commentaire
exécutable Linux important
Debian important
Docker par défaut actuellement
YunoHost dépend du .deb
ArchLinux (AUR) AUR (en) - duniter
nix à voir
RPM #260!292
Snap non prévu
Flatpak non prévu
exécutable Windows non prévu
exécutable macOS non prévu

Duniter Squid

Pour l’instant Duniter Squid est moins visible que Duniter, mais comme il est important pour le réseau, il faudra y réfléchir un jour.

paquet CI archi commentaire
Docker par défaut actuellement
Debian souhaitable
exécutable Linux non prévu car node
3 Likes

Le paquet pour ArchLinux est disponible ici (configuration etc… exactement la même procédure que pour le paquet .deb) :

yay -S duniter
vim /etc/duniter/env_file
systemctl start duniter-mirror.service
1 Like

Comment est-ce qu’on peut ajouter des infos dans le README du AUR pour indiquer quel est le réseau par défaut (dispo avec duniter --chain=gdev) ? Et bien sûr quand on aura sorti la Ğ1 il faudra que le réseau par défaut soit le réseau Ğ1.

Il reprend directement les services et le fichier de configuration par défaut du dépôt git, ressources/debian/. Lorsqu’on mettra une nouvelle version sur le git, il faudra effectuer un commit sur l’AUR pour changer la version et le lien vers la source, ce qui permettra de le maintenir à jour également.

Une fois installé, c’est exactement pareil que sous Debian donc la même doc s’applique.

2 Likes

Comme j’ai commencé à travailler sur le rpm, une réflexion met passé par la tête, il faudra qu’on pense à signer les releases (et du coup les .deb et rpm).

Bon ça peut s’inclure facilement dans la CI:

Au passage j’ai remarqué que le paquet Debian utilise /home/duniter , ça serait pas mieux quelque chose de plus “standard” comme /var/lib/duniter ? (et de fournir dans le package un profil apparmor comme fait Tor).

2 Likes

Tu as raison, ce serait super de signer les releases ! Automatiquement avec une clé GPG sécurisée sur le gitlab d’abord, et éventuellement au cas par cas avec nos clés Ğ1 (mais manuellement du coup).

Hésite pas à proposer des modifications pour le paquet debian également, je suis d’accord qu’il faut s’aligner sur les standards des OS pour surprendre le moins possible les utilisateurices dans leurs habitudes. Le paquet actuel est là pour montrer qu’on a l’intention d’avancer dans cette voie, mais on n’en est qu’au début, et actuellement il n’y a qu’un nœud gdev forgeron qui l’utilise.

2 Likes