Comment s’est passée l’expérience
La semaine dernière, j’étais en vacances et, à cause d’un concours de circonstances, je ne suis parti nulle part. Avec le temps que j’avais sous la main, j’ai décidé d’essayer caddy server, qui est un joli petit serveur écrit en go avec l’intégration de lets encrypt, écrit en Go.
Or, le résultat final est que je n’ai pas réussi à le mettre sur mon serveur, mais la raison n’est pas le logiciel lui-même.
Beaucoup de logiciels en Go manquent de paquets par distribution et, après avoir essayé d’empaqueter caddy, je ne peux pas du tout leur en vouloir.
Pour ceux qui ne connaissent pas la nature de Go, il compile des binaires statiques ; cela a ses avantages et ses inconvénients, mais un avantage que l’on ne peut nier est que, comme moyen de distribution, un binaire unique est très facile à distribuer.
Je n’avais que reconditionné des binaires debian auparavant, alors j’ai tenté le coup, à quel point cela pouvait-il être difficile ?
J’ai découvert que les outils disponibles, du moins pour ma distribution de prédilection (Ubuntu), sont assez peu conviviaux. L’expérience de base d’empaquetage suggérée fait usage de bazaar, de plugins bazaar, de launchpad et de debhelpers. La documentation est surtout référentielle (c’est-à-dire plus de pages de manuel que de howtos/tutoriels) et, si je devais créer un paquet pour une distribution officielle, j’aurais dû trouver moi-même le moyen d’apprendre tous les rouages internes et la politique de la chose. Apprendre à empaqueter « rapidement » n’est pas très possible à moins de vouloir finir avec un ensemble de connaissances plein de trous.
J’ai finalement abouti à ce qu’on appelle un paquet native, ce qui signifie qu’il n’est pas basé sur une source upstream (ce qui est un mensonge, mais je n’ai trouvé aucune manière correcte d’organiser mon projet et ses dépendances de façon à ce que les helpers dpkg ne se plaignent pas de manières très peu utiles)
J’ai finalement abouti à un paquet qui me satisfait (et fonctionne sur n’importe quel amd64, i386 et arm64 à partir de trusty) ; le ppa déclare ne supporter que trusty, vivid et xenial parce que ce sont les seules distributions qui ont Go 1.6, requis pour la compilation (en règle générale, un paquet ne peut être compilé par launchpad que pour une distro qui a des paquets pour toutes les dépendances), mais vous pourriez simplement télécharger le fichier .deb et le mettre où bon vous semble puisque c’est un fichier statique (et quelques réglages de base qui fonctionnent dans n’importe quelle version d’Ubuntu).
Quelques éléments qu’il reste à corriger :
- Faire en sorte que le paquet utilise le format Quilt au lieu de Native.
- Faire en sorte que la configuration pour systemd soit automatique et non manuelle (actuellement, les seuls fichiers package.xxx disponibles dans le paquet sont pour upstart et le service systemd est installé à la main.
- Ajouter des pages de manuel.
- Trouver comment le vendoring est censé être traité dans les paquets go et utiliser le debhelper de go (actuellement, je compile en réalité le paquet à la main et j’empaquette les paquets vendored en utilisant godeps de rogpeppe.
Si vous avez envie de donner un coup de main, tous les patches sont les bienvenus :
- Voici le PPA
- Voici le dépôt bzr pour Wily et plus récents
- Voici le dépôt bzr pour trusty Note il y a deux dépôts parce que le fichier control de debian (ce qui indique à l’environnement à quoi il doit ressembler pour compiler ceci) ne supporte pas les dépendances de compilation optionnelles et, puisque go 1.6 n’est pas golang-go dans Trusty mais un paquet proposé appelé golang1.6, j’ai dû écrire des controls différents.
Ce qui pourrait être amélioré
Je suis à peu près sûr que le système d’empaquetage de debian est assez complet et est un outil très puissant, mais sa documentation n’est pas agencée d’une manière qui rend ce processus facile à prendre en main (il y a fpm pour certains langages, hélas pas pour Go).
Qu’est-ce qui aiderait ? Un tutoriel simple sur :
- Ce qui est attendu.
- Quel est le fichier requis pour systemd
- Ce que les fichiers devraient contenir avec un exemple concret (ils utilisent le paquet hello dans beaucoup de cas, ce qui est un mauvais exemple)
- Comment l’aborder pour différents langages.
- Ce que font les outils helper actuels sous le capot (j’ai passé un bon moment à essayer de découvrir d’où le constructeur fakeroot tirait le gz « upstream »).
Pourquoi ne le fais-je pas ? J’ai reproduit la majeure partie du processus par mimétisme (cargo cult) et, même si je pourrais le décrire un peu, je suis sûr que j’enfreins chacune des règles d’empaquetage de debian.
Ah, la raison pour laquelle je ne l’ai pas mis sur mon serveur ? J’ai passé tout le temps dont je disposais à créer le PPA.