Rukověť baliče RPM - VI (Makro %setup)

23. 6. 2005 | David Nečas | Návody | 7040×

Jak využívat důležité makro %setup a nastavit proměnné prostředí.

Mocné makro %setup

S tuctem zdrojových kódů, z nichž se pokoušíme sestavit balíček, teprve dokážeme ocenit všechny možnosti makra %setup. Začneme ale tím, co vlastně dělá normálně. To mimochodem můžeme studovat na výpisech rpmbuildu. Na začátku každé fáze vypíše řádek Executing(%něco), např.:

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.92023

a následuje výpis, který vypadá úplně, jako by ho vypsal shell při set -x, protože ho vypisuje shell s set -x. Nestačí-li nám to, můžeme se do /var/tmp/rpm-tmp.92023 (číslo se mění podle čísla procesu) podívat – k tomu musíme rpmbuild násilně ukončit nebo nechat skript selhat, neboť po úspěšném dokončení se skript smaže, případně přepíše. Najdeme tam nastavení proměnných a pak:

umask 022
cd /home/yeti/src/RPM/BUILD
rm -rf lobster-1.10
/usr/bin/bzip2 -dc /home/yeti/src/RPM/SOURCES/lobster-1.10.tar.bz2 \
  | tar -xvvf -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd lobster-1.10
[ `/usr/bin/id -u` = '0' ] && /bin/chown -Rhf root .
[ `/usr/bin/id -u` = '0' ] && /bin/chgrp -Rhf root .
/bin/chmod -Rf a+rX,g-w,o-w .

Vidíme, že %setup zařídil, abychom pracovali ve správném adresáři, nepřekážely nám tam pozůstatky předchozích pokusů, rozbalil tarovou kouli se zdrojovým kódem a pokusil se nastavit rozumnější práva (zdrojový kód bývá občas zabalen všelijak). Chceme-li, aby něco dělal jinak či nedělal vůbec, vysvětlíme mu to jednou z mnoha voleb.

%setup -q a klid

Volba -q omezuje upovídanost %setupu, což znamená hlavně to, že nespouští tar -xvvf, ale jen tar -xf. Uvádím ji první, protože je-li použita, musí být první.

%setup -n a název

Občas se adresář, který vznikne po rozbalení zdrojového kódu, jmenuje jinak než %{name}-%{version}. To by %setup zmátlo, a tak mu správné jméno musíme sdělit volbou -n jméno_adresáře. Kdyby se kupříkladu balíček nazýval lobster, jeho zdrojový kód byl crab-1.10.tgz a obsahoval adresář crab/, napíšeme do spec souboru

Name: lobster
Source: ftp://ftp.example.com/pub/lobster/crab-%{version}.tar.bz2
…
%prep
%setup -n crab

%setup -c a adresář

Se zmršenými tarovými koulemi, které autor zabalil bez adresáře a které nám při obyčejném rozbalení zamoří aktuální adresář soubory, se vypořádáme pomocí volby -c. Přidá totiž před implicitní akci (rozbalení archivu) vytvoření adresáře a přechod do něj, tedy řádky

/bin/mkdir -p lobster-1.10
cd lobster-1.10

a po rozbalení už pak adresář nemění.

%setup -D, -T a implicitní akce

Volba -D vypíná mazání adresáře se zdrojovým kódem, tedy řádku

rm -rf lobster-1.10

To se hodí, chceme-li použít %setup několikrát. Pak často potřebujeme i volbu -T, která vypíná impliticní akci, tedy rozbalení tarové koule

/usr/bin/bzip2 -dc /home/yeti/src/RPM/SOURCES/lobster-1.10.tar.bz2 | tar -xvvf -

%setup -a, -b a triky

Volby -a a -b rozbalují konkrétní zdrojové kódy, přičemž -b (before) rozbaluje před vstupem do adresáře a -a (after) po vstupu do adresáře. Jejich argumenty jsou čísla zdrojových souborů z hlavičky. Je to přesně tak zmatené, jak zmateně to zní.

Příklad použití -a. Hlavní soubor lobster-1.10.tar.bz2 obsahuje poloprázdný adresář examples, kam chceme něco doplnit. Příklady máme zabaleny v examples.tar.gz (a rozbalují se pěkně do stejnojmenného adresáře). Použijeme proto -a 1, neboť chceme rozbalit Source1 po vstupu do adresáře:

Source0: ftp://ftp.example.com/pub/lobster/%{name}-%{version}.tar.bz2
Source1: examples.tar.gz
…
%prep
%setup -a 1

Příklad použití -b. Opět chceme něco doplnit do examples, ale příklady jsou v tarové kouli lobster-1.10-examples.tar.gz, která se rozbaluje do lobster-1.10/examples. Použijeme proto -b 1, neboť chceme rozbalit Source1 před vstupem do adresáře:

Source0: ftp://ftp.example.com/pub/lobster/%{name}-%{version}.tar.bz2
Source1: lobster-1.10-examples.tar.gz
…
%prep
%setup -b 1

Kdo se nebojí o své duševní zdraví, může volby různě kombinovat.

Proměnné prostředí

Jak to, že jednou píši o RPM_BUILD_ROOT, jindy o %buildroot, jaký je mezi nimi vztah? Zde se to vysvětlí.

Když rpmbuild skládá skript, který realizuje některou fázi kompilace, zapíše na jeho začátek mimo jiné zhruba toto (kdo chce vědět, co tam opravdu zapíše, ať se podívá):

RPM_SOURCE_DIR="%{_sourcedir}"
RPM_BUILD_DIR="%{_builddir}"
RPM_OPT_FLAGS="%{optflags}"
RPM_ARCH="%{_arch}"
RPM_OS="%{_os}"
RPM_DOC_DIR="%{_docdir}"
RPM_PACKAGE_NAME="%{name}"
RPM_PACKAGE_VERSION="%{version}"
RPM_PACKAGE_RELEASE="%{release}"
RPM_BUILD_ROOT="%{buildroot}"

A všechny proměnné pak exportuje. Ve spec souboru jsou tak makra i proměnné prostředí ekvivalentní. Případné pomocné skripty, které můžeme spouštět, samozřejmě makra „nevidí“, ale proměnné v nich můžeme používat.

       

Komentáře