Cómo fue la experiencia
Esta semana pasada tuve vacaciones y, por una serie de circunstancias, no me fui a ningún lado. Con el tiempo disponible decidí probar caddy server, que es un lindo servidorcito escrito en go con integración de lets encrypt, escrito en Go.
Ahora bien, el resultado final es que no logré meterlo en mi servidor, pero la razón no es el software en sí.
Muchos softwares en Go carecen de paquetes por distribución y, después de intentar empaquetar caddy, no puedo culparlos para nada.
Para quienes no están familiarizados con la naturaleza de Go, este compila binarios estáticos; esto tiene sus pros y sus contras, pero un pro que no podemos negar es que, como medio de distribución, un único binario es muy fácil de distribuir.
Solo había reempaquetado binarios de debian antes, así que le di una oportunidad, ¿qué tan difícil podía ser?
Descubrí que las herramientas disponibles, al menos para mi distro de elección (Ubuntu), son bastante poco amigables. La experiencia básica de empaquetado que se sugiere hace uso de bazaar, plugins de bazaar, launchpad y debhelpers. La documentación es mayormente referencial (o sea, más páginas de manual que howtos/tutoriales) y, si tuviera que crear un paquete para distribución oficial, habría tenido que encontrar la manera de aprender por mí mismo todos los detalles internos y la política del asunto. Aprender a empaquetar “rápido” no es algo muy posible a menos que quieras terminar con un conjunto de conocimientos lleno de huecos.
Finalmente terminé con lo que se llama un paquete native, lo que significa que no está basado en una fuente upstream (lo cual es mentira, pero no encontré una manera adecuada de organizar mi proyecto y dependencias de forma que los helpers de dpkg no se quejaran de maneras muy poco útiles)
Finalmente terminé con un paquete que me satisface (y funciona en cualquier amd64, i386 y arm64 desde trusty en adelante); el ppa declara soportar solo trusty, vivid y xenial porque estas son las únicas distribuciones que tienen Go 1.6, requerido para la compilación (como regla, un paquete solo puede ser compilado por launchpad para una distro que tenga paquetes para todas las dependencias), pero podrías simplemente descargar el archivo .deb y ponerlo donde quieras ya que es un archivo estático (y algo de configuración básica que funciona en cualquier versión de Ubuntu).
Algunas cosas que quedan por arreglar:
- Hacer que el paquete use el formato Quilt en lugar de Native.
- Hacer que la configuración para systemd sea automática y no manual (actualmente los únicos archivos package.xxx disponibles en el paquete son para upstart y el servicio de systemd se instala a mano.
- Agregar páginas de manual.
- Averiguar cómo se supone que se trata el vendoring en los paquetes de go y usar el debhelper de go (actualmente en realidad compilo el paquete a mano y empaqueto los paquetes vendored usando godeps de rogpeppe.
Si tenés ganas de dar una mano, todos los parches son bienvenidos:
- Este es el PPA
- Este es el repo bzr para Wily y más nuevos
- Este es el repo bzr para trusty Nota hay dos repos porque el archivo control de debian (lo que le dice al entorno cómo debería verse para compilar esto) no soporta tener dependencias de compilación opcionales y, dado que go 1.6 no es golang-go en Trusty sino un paquete propuesto llamado golang1.6, tuve que escribir controls diferentes.
Qué podría mejorarse
Estoy bastante seguro de que el sistema de empaquetado de debian es bastante completo y es una herramienta muy poderosa, pero su documentación no está organizada de una manera que haga que este proceso sea fácil de adoptar (existe fpm para algunos lenguajes, tristemente no para Go).
¿Qué ayudaría? Un tutorial simple sobre:
- Qué se espera.
- Cuál es el archivo requerido para systemd
- Qué deberían contener los archivos con un ejemplo de la vida real (usan el paquete hello en muchos, lo cual es un mal ejemplo)
- Cómo encararlo para diferentes lenguajes.
- Qué hacen las herramientas helper actuales por debajo (pasé un buen rato tratando de descubrir de dónde estaba sacando el constructor de fakeroot el gz “upstream”).
¿Por qué no lo hago yo? Copié la mayor parte del proceso por cargo cult y, aunque podría describirlo un poco, estoy seguro de que rompo cada una de las reglas de empaquetado de debian.
Ah, ¿la razón por la que no lo metí en mi servidor? Pasé todo el tiempo que tenía creando el PPA.