Qual é o comportamento padrão de% install?

Question

Eu estou tentando construir um RPM usando o -bb flag (pacote% prep% build% install% check). Esta é a saída da etapa% de instalação:

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.2kgeNY
+ umask 022
+ cd /<redacted>/BUILD
+ '[' /<redacted>/BUILDROOT/<redacted>.i386 '!=' / ']'
+ rm -rf /<redacted>/BUILDROOT/<redacted>.i386
++ dirname /<redacted>/BUILDROOT/<redacted>.i386
+ mkdir -p /<redacted>/BUILDROOT
+ mkdir /<redacted>/BUILDROOT/<redacted>.i386
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars

Aqui está o conteúdo desse arquivo tmp:

  RPM_SOURCE_DIR="/<redacted>/SOURCES"
  RPM_BUILD_DIR="/<redacted>/BUILD"
  RPM_OPT_FLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m32 -march=x86-64 -mtune=generic -mfpmath=sse -fasynchronous-unwind-tables"
  RPM_LD_FLAGS="-Wl,-z,relro "
  RPM_ARCH="i386"
  RPM_OS="linux"
  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH RPM_OS
  RPM_DOC_DIR="/usr/share/doc"
  export RPM_DOC_DIR
  RPM_PACKAGE_NAME="<redacted>"
  RPM_PACKAGE_VERSION="<redacted>"
  RPM_PACKAGE_RELEASE="<redacted>"
  export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
  LANG=C
  export LANG
  unset CDPATH DISPLAY ||:
  RPM_BUILD_ROOT="/<redacted>/BUILDROOT/<redacted>.i386"
  export RPM_BUILD_ROOT

  PKG_CONFIG_PATH="%{_PKG_CONFIG_PATH}:/usr/lib/pkgconfig:/usr/share/pkgconfig"
  export PKG_CONFIG_PATH
  set -x
  umask 022
  cd "/<redacted>/BUILD"
    [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"
    mkdir -p 'dirname "$RPM_BUILD_ROOT"'
    mkdir "$RPM_BUILD_ROOT"




    /usr/lib/rpm/check-buildroot

    /usr/lib/rpm/redhat/brp-compress

    /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
    /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump

    /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
    /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
    /usr/lib/rpm/redhat/brp-python-hardlink
    /usr/lib/rpm/redhat/brp-java-repack-jars

Eu não substituí o comportamento% install no meu arquivo de especificação. Meu arquivo de especificações é assim:

<stuff>
%prep
%build
%install
%files
<more stuff>

O comportamento padrão de instalação% está definido na documentação rpm-builder em qualquer lugar? Como eu sei o que vai ser executado?

    

Answer 1

A fase %install em um arquivo de especificação de RPM deve criar uma hierarquia de sistema de arquivos que é descompactada em um sistema quando você instala o rpm resultante. Essa hierarquia inteira deve ser criada no diretório %{buildroot} (AKA $RPM_BUILD_ROOT ) pelos comandos encontrados na seção %install . Seu conteúdo é inserido textualmente (em expansões de macro RPM) em um script que é interpretado por shell - que é a linha:

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.2kgeNY

Agora, se você deixar a fase% install vazia, o conteúdo do script não será - porque ele inicializa várias coisas que um empacotador provavelmente desejará usar durante a instalação ( $RPM_BUILD_ROOT é um dos mais importantes).

O que exatamente a inicialização faz depende da distribuição - verifique o conteúdo do pacote rpm ( rpm -ql rpm ), arquivos como /usr/lib/rpm/macros (podem estar em algum outro lugar do sistema) são bons candidatos para conter macros (RPM) que são expandidos em torno do que você coloca na fase %install do seu arquivo de especificação.

Dito isso, na maioria das vezes (especialmente com software que usa autotools), a parte principal da fase %install deve ser

make install DESTDIR=%{buildroot}

A macro %make_install deve fazer exatamente isso. Algumas distribuições também têm um "atalho" macro semelhante ao RPM, como, e. %makeinstall no openSUSE , que pode oferecer alguns recursos adicionais sobre o upstream genérico um.