¿Debo compilar mi aplicación Haskell a través del archivo RPM SPEC o intentar usar un binario (reproducible) de la canalización de CI?

Question

No he construido un RPM desde cero en 20 años. Entonces podemos decir efectivamente "nunca".

[editar] El requisito para los RPM es proporcionar reversiones, control de versiones, etc. Es innegociable.

Tengo un único binario y un único archivo de configuración que necesito instalar. Es necesario realizar algunas configuraciones con cuentas de usuario y directorios que creo que deberían ser sencillas.

Si quiero una compilación reproducible probada en el proceso de compilación de RPM, tengo que replicar los pasos de nuestra canalización de CI. No trivial. Lo ideal sería poder extraer los archivos deseados desde alguna otra ubicación:

%prep
cp ${somefile} ${another file} $RPM_SOURCE_DIR
%setup
:

es posible? ¿O me falta alguna solución obvia?

Gracias.

Answer 1

Desde mi punto de vista, depende un poco de a qué te diriges exactamente:

Las distribuciones de Linux como Fedora en realidad esperan que sus compilaciones de distribución el software se construya desde el código fuente utilizando el archivo de especificaciones (dentro de un sistema de compilación sellado que también documenta los paquetes/componentes utilizados para la compilación) y consideran que esto es una buena práctica, también para ganar la mayor reproducibilidad. como sea posible.

Sin embargo, puedes simplemente extraer archivos binarios prediseñados y usarlos dentro de un archivo de especificaciones para crear un paquete RPM, un ejemplo abreviado para tu escenario:

# […]
Source0: <binary file>
Source1: <config file>

# […]

%prep
%setup -q -c -T

%build

%install
install -D -p -m 0755 %{SOURCE0} $RPM_BUILD_ROOT%{_bindir}/%{name}
install -D -p -m 0644 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/%{name}.conf

# […]

Si bien esto podría funcionar, debe verificar explícitamente si las dependencias del paquete RPM resultante son adecuadas ( rpm -qp --requires <…>.rpm) o si faltan dependencias de tiempo de ejecución. A menudo hay opciones o parámetros en tiempo de compilación (por ejemplo, CFLAGSo LDFLAGSsoftware escrito en C), así como scripts de posprocesamiento (por ejemplo, /usr/lib/rpm/(redhat/)brp-*) mientras se crea el paquete RPM que agregan elementos específicos de la distribución y/o extraen dependencias de tiempo de ejecución para usted. Esto puede ser relevante para usted o no (y algunos scripts de posprocesamiento también pueden funcionar para archivos binarios prediseñados, pero otros no debido a la falta de opciones de compilación). Si bien estoy empaquetando una gran cantidad de software, no tengo experiencia con Haskell, pero cuando busco algunos paquetes de Fedora, hay paquetes RPM que tienen dependencias de tiempo de ejecución (y si hay dependencias de tiempo de ejecución, estas deben satisfacerse mediante Paquetes RPM, porque así es como funciona RPM; y no es suficiente tener la biblioteca coincidente en algún lugar de su sistema de archivos, porque RPM no lo sabrá a menos que sea proporcionado por un paquete RPM). Por lo tanto, crear un paquete RPM a partir de archivos binarios prediseñados podría generar un paquete RPM sin las dependencias adecuadas, lo que podría revelarse como errores de tiempo de ejecución más adelante.

Con respecto al ejemplo anterior: si bien SourceX:se le puede proporcionar una URL, rpmbuildaún espera que estos archivos estén en el disco en el SOURCESdirectorio al crear el paquete RPM (por lo tanto, cómo ingresan al SOURCESdirectorio depende de usted).

Dado que no mencionaste a qué distribución de Linux te diriges, estoy vinculando la de FedoraDirectrices de embalaje de Haskell aquí, que puede o no proporcionar más inspiración. Y sí, los paquetes RPM pueden tener distribución cruzada, lo que prácticamente a menudo conduce a binarios estáticos dentro de los paquetes RPM, debido a que a menudo hay diferentes versiones de biblioteca/paquete en diferentes distribuciones de Linux.