☰

Devo construir meu aplicativo Haskell por meio do arquivo RPM SPEC ou tentar usar um binário (reproduzível) do pipeline de CI

tag-icon • tag-icon rpm
Devo construir meu aplicativo Haskell por meio do arquivo RPM SPEC ou tentar usar um binário (reproduzível) do pipeline de CI

Não construo um RPM do zero há 20 anos. Portanto, podemos efetivamente dizer “nunca”.

[editar] O requisito para RPMs é fornecer reversões, controle de versão e assim por diante. Não é negociável.

Eu tenho um único binário e um único arquivo de configuração que preciso instalar. Há algumas configurações com contas de usuário e diretórios que precisam acontecer e que acredito que deveriam ser simples.

Se eu quiser uma construção reproduzível testada no processo de construção RPM, tenho que replicar nossas etapas do pipeline de CI. Não trivial. Idealmente, posso simplesmente extrair os arquivos desejados de algum outro local:

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

Isso é possível? Ou estou perdendo alguma solução óbvia.

Obrigado.

Responder1

Do meu ponto de vista, depende um pouco do que você está almejando exatamente:

Distribuições Linux como o Fedora na verdade esperam para suas compilações de distribuição que o software seja construído a partir do código-fonte usando o arquivo de especificações (dentro de um sistema de compilação selado que também documenta os pacotes/componentes usados ​​para compilação) e considera isso uma boa prática, também para obter o máximo de reprodutibilidade que possível.

No entanto, você pode simplesmente extrair binários pré-construídos e usá-los dentro de um arquivo de especificações para construir um pacote RPM, exemplo abreviado para o seu cenário:

# […]
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

# […]

Embora isso possa funcionar, você deve verificar explicitamente se as dependências do pacote RPM resultante são adequadas ( rpm -qp --requires <…>.rpm) ou se faltam dependências de tempo de execução. Muitas vezes existem opções ou parâmetros de tempo de compilação (por exemplo CFLAGS, LDFLAGSsoftware escrito em C), bem como scripts de pós-processamento (por exemplo, /usr/lib/rpm/(redhat/)brp-*) durante a construção do pacote RPM que adicionam material específico de distribuição e/ou extraem dependências de tempo de execução para você. Isso pode ou não ser relevante para você (e alguns scripts de pós-processamento também podem funcionar para binários pré-construídos, mas outros não devido à falta de opções do compilador). Embora eu esteja empacotando muitos softwares, não tenho experiência com Haskell, mas quando olho para alguns pacotes do Fedora, existem pacotes RPM com dependências de tempo de execução (e se houver dependências de tempo de execução, elas devem ser satisfeitas por Pacotes RPM, porque é assim que o RPM funciona e não é suficiente ter a biblioteca correspondente em algum lugar do seu sistema de arquivos, porque o RPM não saberá disso, exceto se for fornecido por um pacote RPM). Assim, construir um pacote RPM a partir de binários pré-construídos pode levar a um pacote RPM sem dependências adequadas, o que pode revelar-se posteriormente como erros de tempo de execução.

Em relação ao exemplo acima: embora SourceX:possa receber uma URL, rpmbuildainda espera esses arquivos no disco no SOURCESdiretório ao construir o pacote RPM (portanto, como eles entrarão no SOURCESdiretório depende de você).

Dado que você não mencionou qual distribuição Linux você está almejando, estou vinculando o FedoraDiretrizes de embalagem Haskell aqui, o que pode ou não fornecer mais inspiração. E sim, os pacotes RPM podem ser de distribuição cruzada, o que praticamente muitas vezes leva a binários estáticos dentro dos pacotes RPM, devido às diferentes versões de bibliotecas/pacotes em diferentes distribuições Linux.

informação relacionada