rpm mock - complexo de rpm

Question

Digamos que eu queira criar um RPM que ofereça um servidor Web Apache com seu próprio OpenSSL:

/mydir/apache_postfix1
/mydir/openssl_postfix1

Como o Apache mod_ssl requer uma instalação real do OpenSSL, eu tenho que configure --prefix=/mydir/openssl , make , make install OpenSSL para /mydir/openssl , então o Apache com mod_ssl pode realmente compilar com configure --with-ssl=/mydir/openssl .

Impensável em um servidor de compilação (Jenkins) sem permissões em nada fora do diretório de tarefas. Mas eu preciso construir o Apache com o OpenSSL e empacotá-lo em um RPM (para entregar vários Apaches pós-fixados, cada um com seu próprio OpenSSL).

Por isso, pensei que mock é a solução (que é mais provável que seja instalada no servidor de compilação do que as permissões de usuário / instalação).

Mas não encontrei uma documentação completa sobre como usar o mock para usar os recursos completos do rpmbuilds.

Eu tentei mock -r epel-7-x68_64 example.src.rpm , mas ele está procurando por /builddir/build/SPECS/example.spec e está falhando ... por quê? de onde ele pegou esse arquivo?

Este foi apenas um exemplo, o problema real consiste em 7 pacotes de software independentes que devem ser configurados / compilados uns contra os outros para que funcionem como um único serviço ... e empacotados em um único RPM para serem entregues pelo Red Hat Satellite. em > 200 servidores ... sem instalá-los no servidor de construção ...

Qualquer ajuda ou um link para documentação / exemplos utilizáveis são altamente apreciáveis!

    

Answer 1

As melhores fontes de documentação seriam o código-fonte simulado , o documentação oficial do rpm , o guia de embalagem do rpm , e qualquer outra documentação qualquer um desses recomendo. Quanto ao seu exemplo publicado, parece que o pacote example.src.rpm não possui um arquivo de especificação adequado no local correto para o mock funcionar.

O mock tomará uma entrada de um arquivo src.rpm para reconstruir, ou você pode usar um diretório de arquivos de especificações e fontes para construir um rpm de origem (SRPM). Com alguma configuração extra, você pode até mesmo usar o mock diretamente com os checkouts do código-fonte. Uma vez que você tenha o mock instalado e um usuário configurado para usá-lo (o mock irá reclamar se você tentar usar como root, um usuário sem privilégios precisa estar no grupo simulado), é bastante simples de usar:

yumdownloader --source openssl
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results openssl-*.src.rpm

Isso reconstruirá a distribuição fornecida pelo OpenSSL e colocará os pacotes resultantes no diretório rpm-results. Para fazer alterações no pacote fornecido, você deve instalar o src.rpm, fazer as alterações e construir os arquivos rpm resultantes:

yumdownloader --source openssl
rpm -ivh openssl-*.src.rpm
# usually this installs to ~/rpmbuild
# make your changes to ~/rpmbuild/SOURCES/* and ~/rpmbuild/SPEC/openssl.spec as necesary
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results --buildsrpm ~/rpmbuild/SPEC/openssl.spec
mock -r epel-7-x68_64 --resultdir=rpm-results rpm-results/openssl-*.src.rpm

Não tenho certeza se versões mais recentes não exigem a compilação de duas etapas (SRPM = > RPM), mas é assim que usamos o simulado na minha loja. Você provavelmente deseja / precisa fazer isso para cada pacote que está tentando reconstruir. Eu não aconselharia empacotar tudo em um único pacote como você pede, mas nada o impede tecnicamente de fazer isso. Você só precisa criar seu próprio arquivo de especificação que combine tudo ou use uma ferramenta diferente, como FPM .

    

Answer 2

Eu sou um mantenedor do Mock, então eu deveria fornecer uma resposta. Mas eu realmente não posso, porque você não especificou o que é realmente um problema.

Eu só posso explicar como o Mock funciona e resolver algumas de suas confusões.

Quando você chamar mock -r fedora-27-x86_64 , o Mock fará (ignorando alguns detalhes chatos):

1. dnf install --installroot /var/lib/mock/fedora-27-x86_64/root @buildsys-build Isso instalará o sistema mínimo em um diretório separado. Além disso, nesta resposta, vou me referir a /var/lib/mock/fedora-27-x86_64/root como $ CHROOT.

2. Mock extrairá seu example.src.rpm . Especialmente, ele colocará o arquivo de especificações em $CHROOT/builddir/build/SPECS e tar ball em $CHROOT/builddir/build/SOURCES .

3. O Mock analisará seu arquivo de especificação e instalará todos os pacotes listados em BuildRequires em $ CHROOT. (Isso é feito como root).

4. Mock, então, irá chroot () para $ CHROOT e rodará lá rpmbuild -ba /builddir/build/SPECS/example.spec . Isso é feito como usuário sem privilégios (com o UID igual ao seu UID). Isso é feito porque executar o rpmbuild sempre foi desencorajado e pode levar a sérios problemas.

Então, se você quiser instalar alguns pacotes adicionais no chroot., você não deve fazer isso a partir do arquivo de especificação chamando yum / dnf install (especialmente porque o rpm não é reentrante). Mas você deve especificar esses pacotes em BuildRequires e fornecer um repositório com esses pacotes.

Você pode fornecer um repositório usando mockchain -a REPOS (o mockchain é uma camada fina em cima do mock) ou por:

cp /etc/mock/fedora-27-x86_64.cfg ~/my-custom-fedora-27-x86_64.cfg
#add your repository to ~/my-custom-fedora-27-x86_64.cfg
mock -r ~/my-custom-fedora-27-x86_64.cfg example.src.rpm

Se você tem 7 pacotes src.rpm que dependem um do outro, então provavelmente a melhor maneira é chamar mockchain 1.src.rpm 2.src.rpm .... 7.src.rpm e o mockchain criará um repositório temporário para resultados e tentará construir esses pacotes de uma maneira ingênua em while at-least-one-package-build do another loop .

Se você especificar qual é realmente o seu problema, posso fornecer uma resposta mais específica.