16.9. Formáty paketů RPC Na Obr. Obrázek 16.5 ukazuje formát požadavku RPC v paketu TCP Protože TCP přenáší proud bajtů a neposkytuje hranice zpráv, musí aplikace poskytnout způsob, jak zprávy oddělit. Sun RPC definuje položku jako požadavek nebo odpověď a každou položku

Kapitola 17. Vytváření obalů a distribuce programů Stále více produktů – a především aspirin – se vyrábí v obalech, které jsou chráněny do té míry, že je spotřebitel již nemůže používat. Dave Barry Tato kapitola je o tom, jak na to

27.1.2. Struktura paketů IP a TCP Protokol IP není orientován na spojení, a proto neposkytuje spolehlivé doručování dat. Pole popsaná v tabulce 27.4 představují hlavičku IP a přidávají se k paketu, když je přijat z transportu.

4.10.1. Filtrování paketů Hlavním, ale ne jediným úkolem firewallu je filtrování paketů. Linux již má vestavěnou bránu firewall a nemusíte ji instalovat samostatně. Přesněji řečeno, jsou dokonce dva: iptables a ipchainy. Umožňují vám řídit provoz, který tudy prochází

14.12.1. Defragmentace paketů Hackeři provádějí mnoho útoků na servery pomocí fragmentovaných paketů. V Linuxu můžete nechat OS sloučit příchozí pakety. Pokud máte monolitické jádro (bez podpory modulů), musíte do souboru zapsat 1

Formát balíčku Jak již bylo zmíněno, distribuce Mint přijímá formát balíčku deb. Tento formát, který byl vyvinut v minulém tisíciletí pro distribuci Debian, od ní zdědilo Ubuntu, což do značné míry předurčilo její úspěch. A po něm - a naše štěstí

Často se ale stává, že potřebujete sestavit balíček s potřebnými možnostmi (povolit podporu pro mysql, postgresql nebo cyrus-sasl2 atd.), které nejsou v balíčku rpm dodávaném na distribučním disku. Cestou z této situace je sestavení vlastního balíčku.

Aby bylo sestavení rpm balíčků snazší, existuje balíček speciálně navržený pro tento účel – rpm-build.

# rpm -qi rpm-build Název: rpm-build Přemístění: (nelze přemístit) Verze: 4.3.3 Dodavatel: CentOS Vydání: 7_nonptl Datum sestavení: Po 21. února 2005 20:21:52 Datum instalace: So 09. dubna 2005 14:57 Build Host: guru.build.karan.org Skupina: Vývoj/Nástroje Zdroj RPM: rpm-4.3.3-7_nonptl.src.rpm Velikost: 1576124 Licence: GPL Podpis: DSA/SHA1, Ne 27. února 2005 00: 36:59, ID klíče a53d0bab443e1821 Balíček: Karanbir Singh

Jak je patrné z popisu, tento balíček obsahuje sadu skriptů a programů určených k sestavení balíčků.

Abyste mohli sestavit jakýkoli balíček, musíte si nejprve stáhnout tzv. Zdroje pro sestavení balíčku jsou obvykle soubory s příponou src.rpm. Někdy, jako v případě courier-imap, je ve zdrojovém kódu zahrnut soubor spec.

Stránka www.rpmfind.net je velmi pohodlná pro vyhledávání balíčků rpm a src.rpm. Například jsme našli balíček, který jsme potřebovali - postfix, squid atd. Okamžitě zjistíme, které balíčky jsou potřeba k jeho sestavení. Zde je standardní stránka s informacemi o balíčku pro postix i squid. Obsahuje také kontrolní součet pro ověření integrity balíčku.

Poté, co obdržíme zdroje a ověříme jejich integritu, musíme nainstalovat příslušný balíček.

# rpm -ivh postfix-2.2.8-1.2.src.rpm 1:postfix ################################ ############

Po provedení této operace byly zdroje postfixu a všechny potřebné části a také skripty nainstalovány do /usr/src/redhat/SOURCES/ a soubor spec (pokyny pro sestavení balíčku rpm) do /usr/src/ redhat/SPECS/.

# ls /usr/src/redhat/SOURCES/ pflogsumm-1.1.0.tar.gz postfix-etc-init.d-postfix postfix-2.1.1-config.patch postfix-hostname-fqdn.patch postfix-2.1.1 -obsolete.patch postfix-large-fs.patch postfix-2.1.5-aliases.patch postfix-pam.conf postfix-2.2.5-cyrus.patch postfix-sasl.conf postfix-2.2.8.tar.gz README- Postfix-SASL-RedHat.txt postfix-alternatives.patch # ls /usr/src/redhat/SPECS/ postfix.spec

Toto je výchozí umístění souboru při instalaci src.rpm. V zásadě názvy složek mluví samy za sebe.

Abyste mohli začít sestavovat balíček, musíte přejít do složky se souborem spec a spustit následující příkaz

# cd /usr/src/redhat/SPECS/ # rpmbuild -ba --target=i686 postfix.spec Platformy k sestavení: i686 sestavení pro platformu i686 Spuštěno (%prep): /bin/sh -e /var/tmp/rpm -tmp.82019 + umask 022 + cd /usr/src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 + /bin/gzip -dc /usr/src /redhat/SOURCES/postfix-2.2.8.tar.gz + tar -xf - + STATUS=0 + "[" 0 -ne 0 "]" + cd postfix-2.2.8 ++ /usr/bin/id - u + "[" 0 = 0 "]" + /bin/chown -Rhf root . ++ /usr/bin/id -u + "[" 0 = 0 "]" + /bin/chgrp -Rhf root . + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo "Patch #1 (postfix-2.1.1-config.patch):" Patch #1 (postfix-2.1.1-config.patch): + patch -p1 -b --suffix .config -s ... ... ... Zaznamenáno: /usr/src/redhat/SRPMS/postfix-2.2.8-1.2.src.rpm Zaznamenáno: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2 .i686 .rpm Zaznamenáno: /usr/src/redhat/RPMS/i686/postfix-pflogsumm-2.2.8-1.2.i686.rpm Spuštěno (%clean): /bin/sh -e /var/tmp/rpm- tmp.73987 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix-2.2.8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

Z posledních řádků můžete vidět, že hotový rpm balíček se nazývá postfix-2.2.8-1.2.i686.rpm a je uložen ve složce /usr/src/redhat/RPMS/i686/, protože při sestavování balíčku jsme specifikovali klíč --target=i686 .

Vlastní montáž by neměla způsobit žádné problémy. Co když ale potřebujeme sestavit balíček s vlastními možnostmi, například povolit podporu mysql nebo sasl2 atd.? Pro tyto účely budete muset upravit soubor spec.

Podívejme se na část postfixového spec souboru Je třeba poznamenat, že postfix má nestandardní spec soubor, abych tak řekl.

Například jsme chtěli sestavit postfix s podporou MySQL, abychom to udělali, hned na začátku změníme %define MYSQL 0 na %define MYSQL 1. a spustíme příkaz znovu

# rpmbuild -ba --target=i686 postfix.spec Platformy k sestavení: Chyba platformy i686 Build for i686: Neuspokojené závislosti sestavení: pro postfix-2.2.8-1.2.i686 je potřeba mysql-devel

Píše nám, že k jeho sestavení potřebujeme nainstalovat balíček mysql-devel. Vezměte prosím na vědomí, že verze není specifikována, to znamená, že můžete nainstalovat jakoukoli verzi, kterou postfix podporuje, nebo balíček, který potřebujete.

Pokud byste sestavovali ze zdroje, museli byste si sami zjistit, jaké balíčky jsou k sestavení daného balíčku potřeba. To je jedna z výhod vytváření z src.rpm ve srovnání s tar.gz nebo tar.bz2.

Nainstalujte příslušný balíček

# rpm -ivh MySQL-devel-4.1.9-0.i386.rpm Příprava... ############################ ### ############## 1:Vývoj MySQL ############################ ### ##############

A restartujeme sestavení postfixu. Tentokrát vidíme, že všechny potřebné balíčky pro sestavení jsou nainstalovány a nyní už jen zbývá počkat na dokončení sestavení.

# rpmbuild -ba --target=i686 postfix.spec Platformy k sestavení: Sestavení i686 pro platformu i686 Spuštěno (%prep): /bin/sh -e /var/tmp/rpm-tmp.86320 + umask 022 + cd /usr /src/redhat/BUILD + umask 022 + cd /usr/src/redhat/BUILD + rm -rf postfix-2.2.8 ... ... ... Zaznamenáno v: /usr/src/redhat/SRPMS/postfix - 2.2.8-1.2.src.rpm Napsal: /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Napsal: /usr/src/redhat/RPMS/i686/postfix -pflogsumm- 2.2.8-1.2.i686.rpm Spuštěno (%clean): /bin/sh -e /var/tmp/rpm-tmp.52381 + umask 022 + cd /usr/src/redhat/BUILD + cd postfix -2.2. 8 + /bin/rm -rf /var/tmp/postfix-buildroot + exit 0

Celý balíček máme sestavený, teď ho musíme nainstalovat a užívat si života.

# rpm -ivh /usr/src/redhat/RPMS/i686/postfix-2.2.8-1.2.i686.rpm Příprava... #################### ######################### 1:postfix ###################### ### ####################

Pro lepší pochopení se podíváme na sestavení squid, které má standardnější strukturu souborů spec. Jako vždy nejprve nainstalujte src.rpm a nezapomeňte zkontrolovat velikost a kontrolní součet.

# rpm -ivh chobotnice-2.5.STABLE11-2.src.rpm 1:chobotnice ############################### ### ############

Všechny možné klíče zjistíte následovně.

# cd /usr/src/redhat/SPECS # rpmbuild --bp squid.spec # cd ../BUILD/squid-2.5.STABLE11/ # ./configure --help Použití: configure Možnosti: Konfigurace: --cache-file =Výsledky testu mezipaměti SOUBORU v SOUBORU --pomozte vytisknout tuto zprávu --no-vytvořit nevytvářet výstupní soubory --tichý, --tichý netisknout zprávy „kontrola...“ --site-file=SOUBOR použít SOUBOR jako soubor webu --version tiskne verzi autoconf, která vytvořila konfiguraci Názvy adresářů a souborů: --prefix=PREFIX instalace souborů nezávislých na architektuře v PREFIX --exec-prefix=EPREFIX instalace souborů závislých na architektuře v EPREFIX --bindir=DIR uživatelské spustitelné soubory v DIR --sbindir=Spustitelné soubory správce systému DIR v DIR --libexecdir=Spustitelné soubory DIR programu v DIR --datadir=DIR pouze pro čtení architektura nezávislá data v DIR --sysconfdir=DIR pouze pro čtení dat jednoho stroje v DIR --sharedstatedir=DIR upravitelná data v DIR nezávislá na architektuře --localstatedir=DIR upravitelná na jednom počítači v DIR --libdir=Knihovny objektového kódu DIR v DIR --includedir=DIR C hlavičkové soubory v DIR --oldincludedir=DIR C hlavičkové soubory pro non-gcc v DIR --infodir=Informační dokumentace DIR v DIR --mandir=DIR manuálová dokumentace v DIR --srcdir=DIR najít zdroje v DIR --program-prefix=PREFIX předpona PREFIX k názvům nainstalovaných programů --program-suffix=SUFFIX připojit SUFFIX k názvům nainstalovaných programů --program-transform-name=PROGRAM spustit sed PROGRAM na názvech nainstalovaných programů Typ hostitele: --build=BUILD konfigurovat pro sestavení na BUILD --host=HOST konfigurovat pro HOST --target=CÍL nakonfigurujte pro CÍL Funkce a balíčky: --disable-FEATURE neobsahují FUNKCI (stejně jako --enable-FEATURE=no) --enable-FEATURE[=ARG] zahrnují FUNKCI --with-BACKAGE[= ARG] použijte PACKAGE --without-PACKAGE nepoužívejte PACKAGE (stejně jako --with-PACKAGE=no) --x-includes=Soubory DIR X jsou v DIR --x-libraries=Soubory knihovny DIR X jsou v DIR --enable a --s rozpoznanými možnostmi: --disable-dependency-tracking Zrychluje jednorázové sestavení --enable-dependency-tracking Neodmítat pomalé extraktory závislostí --enable-maintainer-mode enable, aby pravidla a závislosti nebyly užitečné (a někdy matoucí) k příležitostnému instalátoru --enable-dlmalloc[=LIB] Zkompilujte a použijte balíček malloc od Douga Lea --enable-gnuregex Zkompilujte GNUregex. Pokud nemáte důvod tuto možnost používat, neměli byste ji povolit. Tento soubor knihovny je obvykle vyžadován pouze na Windows a velmi starých unixových boxech, které nemají vestavěnou vlastní knihovnu regulárních výrazů. --enable-xmalloc-statistics Zobrazit statistiky malloc na stavové stránce --enable-carp Povolit podporu CARP --enable-async-io[=N_THREADS] Zkratka pro --with-aufs-threads=N_THREADS --with-pthreads -- enable-storeio=ufs,aufs --with-aufs-threads=N_THREADS Vylaďte počet pracovních vláken pro úložiště objektů aufs. --with-pthreads Použít vlákna POSIX --with-aio Použít POSIX AIO --with-dl Použít dynamické propojení --enable-storeio="seznam modulů" Vytvoří podporu pro seznam modulů úložiště I/O. Výchozí nastavení je pouze sestavení modulu ufs. Viz src/fs pro seznam dostupných modulů nebo sekci Programmers Guide
podrobnosti o tom, jak vytvořit vlastní modul obchodu
--enable-heap-replacement
Možnost zpětné kompatibility. Použijte prosím
místo toho nová směrnice --enable-removal-policies.
--enable-removal-policies="seznam zásad"
Vytvořte podporu pro seznam zásad odstraňování.
Výchozí nastavení je pouze sestavení modulu lru.
Viz src/repl pro seznam dostupných modulů, popř
Podrobnosti o tom, jak na to, naleznete v části 9.9 Programmers Guide
vytvořit vlastní politiku
--enable-icmp Povolit ICMP ping
--enable-delay-pools Povolí fondy zpoždění pro omezení využití šířky pásma
--enable-useragent-log Povolí protokolování hlavičky User-Agent
--enable-referer-log Povolit protokolování hlavičky Referer
--disable-wccp Zakáže protokol koordinace webové mezipaměti
--enable-kill-parent-hack
Zabít rodiče při vypnutí
--enable-snmp Povolit monitorování SNMP
--enable-cachemgr-hostname[=název hostitele]
Nastavit cachemgr.cgi jako výchozí pro tohoto hostitele
--enable-arp-acl Povolit použití seznamů ARP ACL (etherová adresa)
--enable-htcp Povolit protokol HTCP
--enable-ssl Povolí podporu brány ssl pomocí OpenSSL
--with-openssl[=předpona]
Kompilace s knihovnami OpenSSL. Cesta k
vývojové knihovny a hlavičky OpenSSL
instalace může být specifikována, pokud je mimo
standardní systémové adresáře
--enable-forw-via-db Povolit Forw/Via databázi
--enable-cache-digests Použít přehledy mezipaměti
viz http://www.squid-cache.org/FAQ/FAQ-16.html
--enable-default-err-language=lang
Vyberte výchozí jazyk pro chybové stránky (viz
adresář chyb)
--enable-err-languages="lang1 lang2.."
Vyberte jazyky, které chcete nainstalovat. (Vše bude
ve výchozím nastavení nainstalováno)
--with-coss-membuf-size Velikost membuf COSS (výchozí 1048576 bajtů)
--enable-poll Povolí poll() místo select(). Normálně anketa
je upřednostňován před výběrem, ale konfigurovat ví dotaz
je na některých platformách nefunkční. Pokud si myslíte, že jste
chytřejší než konfigurační skript, můžete povolit
anketa s touto možností.
--disable-poll Zakáže použití poll().
--zakázat-http-porušení
To vám umožní odstranit kód, který je znám
porušují specifikaci protokolu HTTP.
--enable-ipf-transparent
pomocí přesměrování síťové adresy IP-Filter.
--enable-pf-transparent
Povolit pro systémy podporu transparentního proxy
pomocí přesměrování síťové adresy PF.
--enable-linux-netfilter
Povolit podporu Transparent Proxy pro Linux 2.4.
--with-large-files Povolit podporu pro velké soubory (protokoly atd.).
--enable-large-cache-files
Povolit podporu pro velké soubory mezipaměti (>2 GB).
VAROVÁNÍ: Tato volba změní formát mezipaměti na disku
--with-build-environment=model
Prostředí sestavení, které se má použít. Normálně jeden z
POSIX_V6_ILP32_OFF32 32 bitů
POSIX_V6_ILP32_OFFBIG 32 bitů s podporou velkých souborů
POSIX_V6_LP64_OFF64 64 bitů
POSIX_V6_LPBIG_OFFBIG velké ukazatele a soubory
XBS5_ILP32_OFF32 32 bitů (starší)
XBS5_ILP32_OFFBIG 32 bitů s podporou velkých souborů
XBS5_LP64_OFF64 64 bitů (starší)
XBS5_LPBIG_OFFBIG velké ukazatele a soubory
default Výchozí pro váš OS
--enable-leakfinder
Povolit kód pro vyhledávání netěsností. Povolit pouze toto
nic nedělá; musíte také upravit zdroj
kód pro použití funkcí hledání úniků. Pravděpodobně
Užitečné pouze pro hackery.
--disable-ident-lookups
To vám umožní odstranit kód, který funguje
Vyhledávání identity (RFC 931).
--disable-internal-dns Toto zabrání Squidu přímo odesílat a
příjem zpráv DNS a místo toho povolí
staré externí procesy "dnsserver".
--enable-truncate Toto používá truncate() místo unlink() když
odstranění souborů mezipaměti. Truncate dává trochu
zlepšení výkonu, ale může způsobit problémy
při použití s ​​asynchronními I/O. Truncate využívá více
inody souborového systému než odpojit..
--disable-hostname-checks
Squid ve výchozím nastavení odmítá jakékoli názvy hostitelů
liché znaky v jejich jménu, které se mají přizpůsobit
internetové standardy. Pokud s tím nesouhlasíte
tento přepínač můžete použít k vypnutí jakéhokoli takového
kontroluje, za předpokladu, že resolver používaný
Squid neodmítá taková jména hostitelů.. Toto
může být požadováno, aby se účastnil testů pro
mezinárodních doménových jmen.
--enable-underscores Squid ve výchozím nastavení odmítá jakékoli názvy hostitelů s _
jejich jménem, ​​aby odpovídaly internetovým standardům.
Pokud s tím nesouhlasíte, můžete povolit _
názvy hostitelů pomocí tohoto přepínače za předpokladu, že
knihovna resolveru na hostiteli, kde běží Squid
neodmítá _ v názvech hostitelů...
--enable-auth="seznam modulů schématu ověřování"
Vytvořte podporu pro seznam schémat ověřování.
Výchozí nastavení je vytvořit podporu pro základní schéma.
Viz src/auth pro seznam dostupných modulů, popř
Schémata ověřování sekce Programmers Guide
podrobnosti o tom, jak vytvořit vlastní schéma ověřování
modul
--enable-auth-modules="seznam pomocníků"
Zpětná kompatibilita alias pro
--enable-basic-auth-helpers
--enable-basic-auth-helpers="seznam pomocníků"
Tato volba vybírá základní schéma proxy_auth
pomocníky stavět a instalovat jako součást normálu
budovat proces. Pro seznam dostupných
helpers viz adresář helpers/basic_auth.
--enable-ntlm-auth-helpers="seznam pomocníků"
Tato volba vybírá, které proxy_auth pomocníky ntlm
postavit a nainstalovat jako součást normálního sestavení
proces. Seznam dostupných pomocníků viz
adresář helpers/ntlm_auth.
--enable-digest-auth-helpers="seznam pomocníků"
Tato možnost vybírá, které schéma ověřování digest
pomocníky k sestavení a instalaci jako součást normálního sestavení
adresář helpers/digest_auth.
--enable-ntlm-fail-open Povolí selhání NTLM otevření, kde dojde k selhání pomocníka
jeden z kroků autentizace může chobotnici povolit
stále ověřovat uživatele.
--enable-external-acl-helpers="seznam pomocníků"
Tato volba vybírá, které externí_acl pomocníky mají
postavit a nainstalovat jako součást normálního sestavení
proces. Seznam dostupných pomocníků viz
helpers/external_acl adresář.
--with-samba-sources=/cesta/ke/samba-source-tree
Cesta, kde mohou být správné zdrojové soubory Samba
nalezené při stavbě pomocníků winbind. (výchozí na
použít interní kopie hlaviček ze Samba-2.2.7)

Disable-unlinkd Nepoužívejte unlinkd
--enable-stacktraces Povolit automatické volání zpětné sledování fatálních chyb
--enable-x-accelerator-vary
Povolit podporu pro X-Accelerator-Vary
HTTP hlavička. Lze použít k označení
rozptyl v rámci nastavení akcelerátoru.
Obvykle se používá společně s jiným kódem
který k požadavkům přidává vlastní hlavičky HTTP.
--with-maxfd=N Přepíše maximální počet deskriptorů souborů. Užitečný
pokud sestavujete jako jiný uživatel, který nemá oprávnění
použít požadovaný počet deskriptorů souborů
výsledný binární k podpoře

Po nalezení požadovaného klíče jej přidejte do %configure. Například chceme postavit chobotnici s podporou ssl. Z nápovědy jsme zjistili, že k tomu potřebujeme přidat dva klíče --enable-ssl a --with-openssl. Provedeme příslušné změny

Uložte soubor a začněte stavět.

# rpmbuild -ba --target=athlon squid.spec Platformy k sestavení: athlon Sestavení pro platformu athlon Spuštění (%prep): /bin/sh -e /var/tmp/rpm-tmp.59199 + umask 022 + cd / usr /src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf squid-2.5.STABLE11 + /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/squid-2.5.STABLE11. tar .bz2 ... ... SSL brána pomocí OpenSSL povolena
Použití implementace OpenSSL MD5 ... ... ... Zaznamenáno: /usr/src/redhat/SRPMS/squid-2.5.STABLE11-2.src.rpm Zaznamenáno: /usr/src/redhat/RPMS/athlon/squid-2.5. STABLE11- 2.athlon.rpm Running(%clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src/redhat/BUILD + cd squid-2.5.STABLE11 + rm - rf /var/tmp/squid-2.5.STABLE11-root + exit 0 Execute(--clean): /bin/sh -e /var/tmp/rpm-tmp.7322 + umask 022 + cd /usr/src /redhat /BUILD + rm -rf squid-2.5.STABLE11 + exit 0

Všechny chobotnice jsme úspěšně shromáždili, nyní zbývá pouze nainstalovat nebo aktualizovat.

Jsou to dva vozy, identická verze/oblouk SLES.

Instalováno na počítači #A software"foo", které můžeme vidět pomocí rpm -qa .

Stroj #B potřebuje nainstalovat software "foo".

foo.rpm není přístupný z žádného zdroje, internetu atd.

Otázka

Protože byl balíček foo.rpm nainstalován na počítači #A, můžeme na něm vytvořit soubor foo.rpm z již nainstalované soubory?

Myslím, že v rpm existují i ​​před/post skripty. Takže můžete nainstalovat foo.rpm ( se závislostmi?).

2 Řešení shromažďují webový formulář pro „Jak vytvořit balíček RPM z nainstalovaných souborů?

Je to možné, ale je velmi obtížné to udělat správně. Pokud jste zoufalí, můžete tvořit nový soubor RPM .spec a vytvořte „falešný“ zdrojový soubor RPM (SRPM), který pak lze použít k vytvoření výsledného souboru RPM pomocí rpmbuild --rebuild .

Pokračoval bych v hledání skutečných RPM. Ve své otázce neuvádíte co, ale mám zkušenost, že na internetu se dá najít cokoli, pokud víte, jak to hledat. Našel jsem staré verze RPM pro distribuce červená čepice, které se nepoužívají přes 10 let, takže bych těžko věřil, že v těchto otáčkách nejsou žádné zbytky.

Můžete se také často vrátit ke zdroji aplikace, který je obsažen v RPM, a použít jej k obnovení RPM. Zdrojové aplikace často obsahují nezbytný soubor .spec, který se používá k obnovení RPM.

Nakonec můžete získat zdrojový soubor a soubor .spec ze služby sestavení, například pro distribuce založené na Koji pro Red Hat. SuSE podporuje podobné služby sestavení, takže je můžete vyhledat a získat staré artefakty sestavení.

Binární soubory jako

Tuto metodu můžete použít ke zvýšení skutečné hodnoty spustitelné soubory z jednoho systému a stáhnout je pro nasazení v jiném systému.

auto A

$ rpm -ql | xargs tar -zcvf /tmp/program.tgz

auto B

$ tar -zxvf /cesta/k/vasemu/programu.tgz

RPM verze od SLES

Podle jednoho z příspěvků v tomto vlákně: Re: Jak vytvořit RPM před nainstalovanými rpm balíčky na SLES mají mít přepínač --repackage. Toto neexistuje ve verzi Red Hat (na Fedoře nebo CentOS). Ale podle příspěvku to můžete použít takto:

$ rpm -e --repackage

Poté zde najdete své RPM:

/var/spool/repackage

Pomocí rpmerizoru

Rpmerizor je nástroj/skript třetí strany, který si můžete nainstalovat a který přebalí zdrojové soubory do příslušného RPM. Použití tohoto skriptu je k dispozici zde pod názvem: manuálová stránka rpmerizor.

výňatek

Rpmerizor je skript, který umožňuje vytvořit RPM balíček z nainstalovaných souborů. Stačí zadat soubory na příkazovém řádku a odpovědět na několik interaktivních otázek k vyplnění metadat rpm (název balíčku, verze...). Můžete jej také použít v dávkovém režimu s možnostmi příkazový řádek pro metadata.

Pomocí rpmrebuild

Nezaměňujte s nástrojem pro sestavení rpmbuild, rpmrebuild je další skript třetí strany, který můžete použít k přebalení již nainstalovaného RPM.

výňatek

rpmrebuild je nástroj pro vytvoření souboru RPM z balíčku, který již byl nainstalován v základním používání, použití rpmrebuild nevyžaduje žádné znalosti o vytváření rpm. (V Debianu je ekvivalentním produktem dpkg-repack).

příklad

Řekněme, že chceme znovu zabalit server openssh.

$ rpm -aq | grep openssh-server openssh-server-6.2p2-8.fc19.x86_64

Nyní balíček:

$ rpmrebuild openssh-server-6.2p2-8.fc19.x86_64 /usr/lib/rpmrebuild/rpmrebuild.sh: VAROVÁNÍ: některé soubory byly upraveny: ..?...... c /etc/ssh/sshd_config . .?...... c /etc/sysconfig/sshd Chcete pokračovat? (y/N) y Chcete změnit číslo vydání? (y/N) n výsledek: /root/rpmbuild/RPMS/x86_64/openssh-server-6.2p2-8.fc19.x86_64.rpm

• Re: Jak vytvořit balíčky nainstalované RPM

Zpravidla ne.

S trochou rpm -qi a rpm -q --changelog získáte představu o tom, odkud balíček pochází.

Pokud byl postaven na systému, na kterém běží, stále můžete použít soubor spec použitý ke generování skutečných otáček, pokud ne obojí.

rpm -q --list Zobrazuje všechny soubory, které balíček nasadí.

rpm -q --scripts Chcete-li zobrazit všechny skripty, které se spouštějí při instalaci (nebo odinstalaci), balíček může poskytnout co nejméně informací o jeho účelu jako soubory, které jsou nasazeny.

A všechny závislosti, které je třeba nainstalovat, lze najít pomocí rpm -q --requires

Všechny příručky, které jsem našel na internetu, se ve většině případů dělí na dva typy:
— překlad dokumentace (kterou vám stále doporučuji přečíst, protože můj článek pokryje pouze část informací, které budete v budoucnu potřebovat)
— stručné pokyny, jak spustit rpmbuild, když už máme vše.
Osobně jsem se potýkal s nutností sestavit balíček ze zdroje, se kterým nic nebylo a hlavně spec soubor, ze kterého se balíček sestaví. Výsledkem je, že napíšeme vlastní soubor spec pro sestavení balíčku a okamžitě tam přidáme naše vlastní konfigurace (tento problém také není příliš dobře pokryt).

Budu sestavovat balíček ze zdrojů ffmpeg pro AirVideoServer, který jsem již popsal jako . Jsem zastáncem instalace aplikací přes něj v distribuci, která používá správce balíčků, a proto na CentOS nemám rád vytváření softwaru ze zdroje. Z tohoto důvodu jsem se rozhodl vše sbírat do pytlů pro sebe. Sestavení také nezbytného lame (dodává se včetně souborů spec) a x264 (po přečtení tohoto článku si pro něj můžete napsat soubor spec) by vám v budoucnu nemělo dělat problémy.

Nejprve tedy musíme nastavit „prostředí“, ve kterém budeme balíček přebírat. Nedoporučuje se vytvářet balíčky pod rootem, takže vytvoříme samostatného uživatele, ale prozatím nainstalujeme veškerý potřebný software:

Yum install gcc gcc-c++ automake autoconf libtool yasm nasm ncurses-devel git ftp rpmdevtools

Nyní vytvoříme speciálního uživatele

Useradd rpmbuild

a pojďme pod něj

Su - rpmbuild

provedeme příkaz

Rpmdev-setuptree

tak, aby nasadil potřebnou adresářovou strukturu, kterou můžeme sestavit
A nyní můžeme přistoupit přímo k montáži.
Potřebujeme samotný zdroj

Wget http://inmethod.com/airvideo/download/ffmpeg-for-2.4.5-beta7.tar.bz2

rozvinout to

Tar -xjf ffmpeg-for-2.4.5-beta7.tar.bz2

Umístíme vedle něj konfigurační soubor s obsahem:

Nano airvideoserver.conf path.ffmpeg = /usr/bin/ffmpeg password = titles.encoding = utf-8 titles.font = Verdana folders = Filmy:/home/share/films

Zde si stáhneme soubor serveru:

Wget http://inmethod.com/airvideo/download/linux/alpha6/AirVideoServerLinux.jar

A úvodní skript:

Nano AirVideoServer #!/bin/bash #chkconfig: - 80 20 #description: AirVideo server # Knihovna zdrojových funkcí. . /etc/rc.d/init.d/functions PREFIX_DIR=/usr/local/AirVideo případ "$1" na začátku) echo -n "Spouštění serveru AirVideo: " daemon java -jar $(PREFIX_DIR)/AirVideoServerLinux.jar $( PREFIX_DIR)/properties.conf > /dev/null 2>&1 & [ $? -eq 0 ] && úspěch || selhání echo ;; stop) echo -n "Zastavuji server AirVideo: " killproc java echo ;; status) status java ;; restartovat | znovu načíst) $0 stop ; 0 $ start ;; *) echo "Použití: airvideo (start|stop|stav|reload|restart" exit 1;; esac

Nyní můžeme přejít k psaní našeho souboru spec pro sestavu.
Nejprve máme různé nadpisy. Název balíčku, verze a vydání jsou důležité; určují, do kterého adresáře bude zdroj nasazen před sestavením. V Source1, Source2 a Source3 označujeme naše 3 další soubory, config, server a init skript, které musí být přidány do balíčku při sestavování.

Název: ffmpeg Verze: 2.4.5 Vydání: beta7 Shrnutí: ffmpeg pro AirVideoServer Licence: GPL URL: http://inmethod.com/airvideo/ Zdroj: http://inmethod.com/airvideo/download/ffmpeg-for-2.4 .5-beta7.tar.bz2 Zdroj1: airvideoserver.conf Zdroj2: AirVideoServer Zdroj3: AirVideoServerLinux.jar BuildRoot: %(_tmppath)/%(název)-for-%(verze)-%(vydání)

%description Nástroj a knihovna pro kódování H264/AVC video streamů pro AirVideoServer.

Sekce %prep je zodpovědná za příkazy potřebné ke spuštění sestavení, takže se nemusím starat o přejmenování adresáře pro formát – pouze pomocí přepínače -n označím, kde se nacházejí rozbalené zdroje

%prep %setup -n /home/rpmbuild/rpmbuild/BUILD/ffmpeg/

Sekce %build je zodpovědná za přímé sestavení zdroje; klíče můžete změnit na ty, které potřebujete, jako při normální montáži a instalaci ze zdrojů:

%build ./configure \ --prefix="%(_prefix)" \ --bindir="%(_bindir)" \ --libdir="%(_libdir)" \ --enable-pthreads \ --disable-shared \ --enable-static \ --enable-gpl \ --enable-libx264 \ --enable-libmp3lame

Sekce %install obsahuje příkazy pro instalaci souborů balíčků do systému; zde musíme dodatečně specifikovat, kam nainstalovat náš konfigurační soubor, server a init skript

%install %(__rm) -rf %(buildroot) %(__make) install DESTDIR="%(buildroot)" mkdir -p $RPM_BUILD_ROOT/usr/local mkdir -p $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE1) $RPM_BUILD_ROOT/usr/local/AirVideo/ install -m 644 %(SOURCE2) $RPM_BUILD_ROOT/etc/init.d install -m 644 %(SOURCE3) $RPM_BUILD_ROOT/usr/local/AirVideo/

Pojďme vyčistit smetí a spustit ldconfig

%clean %(__rm) -rf %(buildroot) %post -p /sbin/ldconfig %postun -p /sbin/ldconfig

Příkazy v sekci %files specifikují seznamy souborů a adresářů, které by měly být s příslušnými atributy zkopírovány ze stromu sestavení do balíčku rpm a poté budou zkopírovány do cílového systému při instalaci tohoto balíčku.

%files %defattr(-,root,root,-) %doc KOPÍROVÁNÍ* CREDITS README* %(_bindir)/avconv %(_bindir)/avprobe %(_bindir)/avserver %(_bindir)/ffmpeg /usr/include/* /usr/lib64/* /usr/share/avconv/* /usr/local/AirVideo/airvideoserver.conf /etc/init.d/AirVideoServer /usr/local/AirVideo/AirVideoServerLinux.jar

Makro %doc označuje soubory dokumentace, autorská práva a další věci.
Tím je náš spec soubor připraven, nyní musíme spustit samotné sestavení

Rpmbuild -bb ffmpeg/ffmpeg.spec

Po úspěšném sestavení balíčku, po dokončení, v adresáři RPMS/_architecture_/ budeme mít náš balíček ffmpeg-2.4.5-beta7.x86_64.rpm, který lze nyní nahrát a nasadit na jakýkoli počítač.

Doufám, že vám tento malý manuál pomůže sestavit si vlastní balíčky pro instalaci s vlastními konfiguračními soubory, které vám později usnadní život.

Nejprve pojďme zjistit, co by mělo být v systému, aby se vytvořil balíček rpm. Musí být nainstalován balíček rpm-build. Bez něj nebude příkaz rpmbuild dostupný. Spolu s ním bude jako závislosti dodána řada balíčků používaných při montáži. V závislostech pro sestavení balíčku v ROSE nebývá zvykem uvádět kompilátor C/C++, z tohoto důvodu budete dříve nebo později potřebovat balíčky gcc a gcc-c++. Všechny ostatní závislosti si musí balíček vyžádat sám . Samozřejmě existují chyby a během procesu montáže si uvědomíte, že jste něco přehlédli, ale to je obvykle poměrně vzácné a není to kritické.

Co to vlastně RPM balíček je? Balíčky RPM se dělí na zdrojové balíčky - src.rpm a balíčky připravené k instalaci - %(arch).rpm. Balíčky src.rpm obsahují původní tarball (zdroj programu), jakékoli další zdroje, části a nejdůležitější soubor specifikací, který řídí proces sestavení. Všechny tyto soubory jsou zabaleny do archivu cpio. Když se pokusíte vstoupit do balíčku src.rpm pomocí správce souborů mc, uvidíš. Balíček také obsahuje některé soubory s informacemi.

Balíčky %(arch).rpm obsahují archiv cpio se soubory, které budou po instalaci distribuovány do příslušných adresářů, informačních souborů a instalačních skriptů.

Setkat se můžete i bez zdrojový kód. Obvykle jsou vytvořeny pro proprietární programy, které nelze zahrnout do distribuce (neexistují žádné zdrojové kódy a binární soubor je třeba nějak předělat nebo je jednoduše zakázáno jeho umístění na zrcadla distribuce). Uvnitř tohoto balíčku je obvykle pouze soubor spec a binární soubor se stáhne a v případě potřeby upraví během instalace balíčku (například v post-scriptu, o kterém bude řeč níže).

Balíčky lze vyzvednout od libovolného uživatele. Nedoporučuje se to dělat jako root, protože existuje možnost, že kořenem instalační sekce bude adresář / a poté příkaz rm -rf %(buildroot) zničí vše na světě. Stává se také, že „ crooked” balíčky neprovedou instalaci správně a neumístí je do dočasného adresáře, ale přímo někam do %(_prefix) (/usr) Některé soubory budou ztraceny, i když to samozřejmě neovlivní výkon balíku na tomto stroji.

Co je potřeba udělat, aby bylo možné balíčky sbírat běžný uživatel? Nejprve musíte ve svém domovském adresáři vytvořit soubor adresáře rpmbuild s následující strukturou:

~/rpmbuild |-- BUILD |-- BUILDROOT |-- RPMS | |-- i586 | |-- x86_64 | `-- noarch |-- ZDROJE |-- SPECIFIKACE `-- SRPMS

Adresáře BUILD , RPMS , SOURCES , SPECS , SRPMS musíte vytvořit ručně, podadresáře adresáře RPMS by se měly vytvářet automaticky během sestavení v závislosti na architektuře.

V ROSE není obvyklé zapisovat tvůrce balíčků a dodavatele do spec souborů; tyto hodnoty jsou nastaveny automaticky sestavovacím systémem ABF. ABF také automaticky podepisuje zkompilované balíčky pomocí klíče odpovídajícího úložiště. Proto se zde těchto otázek nebudeme dotýkat.

Nyní se podívejme, jaký je nejdůležitější soubor balíčku rpm, soubor spec. Vezměme si to například z balíčku stardict. Tento balíček je vhodný pro učení, protože obsahuje několik tarballů (zdroj programu zabalený v tar), je získáno několik balíčků a existuje něco jako diagramy. Soubor spec má obvykle stejný název jako samotný balíček (stardict.spec). Můžete však přidat verzi balíčku (stardict-2.spec), která je užitečná, pokud se snažíte podporovat více větví programů. Můžete tomu dát i jiné jméno, ale to je, mírně řečeno, nepohodlné.

Takže obsah souboru stardict.spec je uveden níže. Za určité sekce okamžitě vložíme komentáře, ale pokud spojíte všechny bloky do stejného souboru, získáte plnohodnotný stardict.spec.

Soubor spec se skládá z částí a záhlaví:

Shrnutí: Slovník StarDict Název: stardict Verze: 2.4.8 Vydání: 4 Licence: GPL URL: Skupina: Uživatelské rozhraní/Desktopy Zdroj0: %(name)-%(version).tar.bz2 Zdroj1: %(name)-tools- %(version).tar.bz2 Patch0: %(name)-2.4.8-desktop.patch

souhrn- stručný popis balíčku, název- Název, Verze- verze, Uvolnění- uvolnit. Poslední tři značky odpovídají definicím maker %(name) , %(version) , %(release) . Často se používají později. název A Verze obvykle stejný jako název tarballu. Pokud se liší, pak se v zásadě není čeho obávat, ale na některých místech v souboru spec budete muset použít nestandardní metody. Pokud sestavujete balíček z cvs, svn atd., pak se doporučuje udělat definici makra %define date 20070422 na úplný začátek souboru (v tomto formátu můžete hádat proč) a Uvolněte značku definovat takto:

Vydání: 0.git%(datum).4

Zdroj*- zdrojové texty, tarbally, jen soubory. V tomto příkladu jsou dva tarbally s různé programy, což značně ztěžuje montáž. Běžné soubory, jako jsou konfigurace, lze jednoduše zkopírovat do sekce %%install pomocí příkazu install. Má jednoduchou syntaxi, install -m mask_as_chmod co jde kam. Pomocí něj můžete také vytvářet adresáře. V našem příkladu není použit, ale více si o něm můžete přečíst u člověka.

Náplast- záplaty, opravy, které jste vy nebo někdo jiný vydali pro tento balíček. Není zvykem měnit zdrojový kód samotného programu a následně jej zabalit do tarballu. Je zvykem aplikovat náplasti. Můžete je provést následovně. Rozbalte původní tarball, pro nás to bude stardict-2.4.8, poté zkopírujte stardict-2.4.8 do stardict-2.4.8.orig. Poté změňte kód v adresáři stardict-2.4.8, ukončete jej a zadejte příkaz diff -ur stardict-2.4.8.orig stardict-2.4.8 > stardict-2.4.8-název_patch.patch. Jak můžete vidět, před přidáním opravy je %(název)-%(verze) balíčku. V samotném souboru spec musíte napsat název opravy bez definic maker. Alespoň verze, určitě. V opačném případě při aktualizaci verze balíčku aktualizujete verzi opravy definovanou makrem %(version) a oprava může být vhodná pro nová verze program bez jakýchkoli změn. Pokud během montáže nebylo možné záplatu aplikovat, měla by být buď předělána tato verze nebo jej zakažte v sekci %setup.

V souborech specifikací balíčků mnoha distribucí můžete také najít v záhlaví definici BuildRoot - adresář, ve kterém se sestavení provádí. V ROSE tato definice není nutná, název BuildRoot je generován automaticky.

BuildRequires: libgnomeui-devel >= 2.2.0 BuildRequires: scrollkeeper BuildRequires: gettext Vyžaduje(post): GConf2 Vyžaduje(post): scrollkeeper Vyžaduje(postun): scrollkeeper

BuildRequires je část, ve které jsou zapsány balíčky, které jsou nutné k sestavení našeho programu, oddělené čárkami nebo mezerami. Můžete je získat z některých souborů README a INSTALL (ačkoli na tom je zřídka něco užitečného), z procesu konfigurace (na tento moment obvykle se jedná o konfigurační skript) a ze samotného procesu sestavení (někdy konfiguraci něco chybí a sestavení se zastaví).

Vyžaduje - tato sekce obsahuje balíčky nebo soubory(!), které bude tento balíček vyžadovat během instalace. Při sestavování budou závislosti automaticky zahrnovat všechny knihovny, které bude náš balíček vyžadovat, ale balíčky můžete zadat i ručně. Rpm také automaticky registruje závislosti perlu, pythonu, mono a některých dalších (všechny tyto závislosti nejsou samozřejmě zapsány v souboru spec, ale v samotném balíčku). Pokud nepotřebujete, aby se závislosti automaticky registrovaly, měli byste do souboru spec přidat novou značku AutoReq: no. Obvykle je předepsán při sestavování proprietárních programů, protože rpm přidává interní závislosti z kompilovaného programu.

Náš příklad používá konstrukce Requires(post) a Requires(postun) pro závislosti v instalačních a odinstalačních skriptech. V zásadě stačí jednoduché Požadavky. Tady není moc co komentovat. Jde jen o to, že samotný StarDict tyto závislosti během provozu nepotřebuje. Jsou potřeba pouze při instalaci a demontáži.

Existuje několik dalších užitečných značek, které zde nejsou použity.

Poskytuje: title1, title2

Jiná jména než %(name), na která bude tento balíček reagovat. Je vhodné uvést, zda jste změnili název balíčku, ale ostatní balíčky nadále závisí na starém názvu.

Zastaralé: jméno1, jméno2

Odebere zadané balíčky při instalaci aktuálního balíčku. Jako by říkali, že tento balíček nahrazuje ty uvedené (z hlediska funkčnosti, sady souborů atd.). Můžete použít název konstrukce< . Тут вы должны сами понимать, что к чему.

Konflikty: titul1, titul2

Jsou uvedeny balíčky, které jsou v konfliktu s aktuálním. Předpokládá se, že tyto balíčky musí být před instalací našeho balíčku ručně odstraněny. Používají se také konstrukce se srovnávacími značkami a verzemi (viz výše).

Navrhuje: title1, title2

- měkký závislosti jsou balíčky, které k danému balíčku přidávají další funkce (například kodeky pro přehrávač médií), ale bez kterých se obejdete.

Epocha: číslo

Obvykle se buď neuvádí vůbec, nebo se rovná 0. Podstatou tohoto parametru je toto. Nechte náš balíček stardict stále mít verzi 2.4.8 a je tam i jeden starší 2.4.5 . Takže pokud stardict 2.4.5 má %(epocha) 1 a pro 2.4.8 - 0 , pak bude balíček 2.4.5 vždy novější než 2.4.8. To vám řekne RPM během instalace. Tento parametr je výhodný, pokud se chcete vrátit k předchozí verzi (samozřejmě, pokud vše dáte do veřejného úložiště a vše stáhnete přes urpmi nebo rpmdrake . Pro „domácí“ potřeby se hodí parametr rpm --force). Pokud je definován tag Epoch: 0, pak bude mít paket přednost před paketem s nedefinovaným tagem Epoch.

BuildArch: architektura

Architektura, pod kterou bude náš balíček sestaven. Pokud tato možnost není zadána, bude balíček vytvořen pro aktuální architekturu. Obvykle je tato volba specifikována za účelem vytvoření balíčku architektury noarch, tedy balíček, který neobsahuje binární soubory.

ExclusiveArch: architektura1 architektura2

Architektury, pro které lze tento balíček sestavit. Obvykle se používá při sestavování modulů pro jádro.

Zde končí hlavička a začínají jednotlivé sekce.

%description StarDict je mezinárodní slovník napsaný pro prostředí GNOME. Má výkonné funkce, jako je „shoda vzorů ve stylu globusu“, „Skenovat výběrové slovo“, „Fuzzy vyhledávání“ atd.

Popis hlavního balíčku, toho s názvem %(name)

%package tools Shrnutí: StarDict-Editor Vyžaduje: %(název) = %(verze)-%(vydání) Skupina: Uživatelské rozhraní/Počítače

Zde vytvoříme nový balíček, jehož název bude %(name)-tools . Pokud potřebujete balíček nazvat úplně jinak, měli byste to udělat například takto: %package -n tools-stardict . Verze nového balíčku je převzata z daného tagu Version. Věnujte pozornost požadavkům. Obsahuje závislost na hlavním balíčku stardict. Pokud by to mělo %(epoch) , pak by bylo nutné specifikovat Vyžaduje: %(název)-%(epocha):%(verze)-%(vydání). Jinak tento balíček jednoduše nebudete moci nainstalovat.

%description tools Jednoduchý nástroj pro StarDict.

Popis druhého balíčku

%prep %setup -q -a1 %patch0 -p1

Sekce %prep zahajuje přípravu na sestavení. %setup rozbalí zdroje. Volba -q nezobrazuje výstup rozbalení archivu. Volba -a1 používá se k rozbalení %(SOURCE1) , druhého tarballu uvnitř(!) adresáře prvního tarballu. Podle toho číslo označuje číslo SOURCE. Parametr se také někdy používá -b, pak se druhý tarball rozbalí do stejného adresáře jako první. Pokud tedy máme jeden tarball, pak možnosti -A, -b se nepoužívají.

Pokud má váš první adresář v tarballu jiný název než %(name)-%(version), pak rpm nebude moci automaticky vstoupit do tohoto adresáře. V tomto případě byste měli trochu změnit %setup. Pokud je v archivu stardict-2.4.8.tar.bz2 první adresář pojmenován například jednoduše stardict , bude to vypadat takto:

%setup -q -n %(jméno) -a1

Ihned po rozbalení balíčku, před %patch , v případě potřeby můžete zkopírovat soubory nebo spustit jakýkoli program pro změnu zdrojů. Řekněme, že zkopírujte soubor Russification nebo opravte nějaký zdrojový kód pomocí sed. Stačí sem zavolat cp, sed nebo něco jiného. Kořenem je zde adresář, do kterého byl rozbalen první tarball (je za něj zodpovědná proměnná $RPM_BUILD_DIR, která se však používá velmi zřídka).

Pomocí % oprav se aplikují opravy. Pokud jste udělali patch, jak jsme psali výše, pak budete mít parametr vždy -p1. Parametr se také často používá -b .název_patch, pro vytvoření zálohy.

%build pushd %(name)-tools-%(version) %configure %make popd %configure %make

Sekce %build je místo, kde je balíček sestaven. Dávejte pozor na pushd a popd. Pomocí těchto příkazů se pohybujeme a opouštíme druhý adresář tarball. Toto bude kořenový adresář po pushd . Po příkazu popd se vrátíme do adresáře prvního tarballu. Pokud tedy máte jeden zdroj, nemusíte tyto příkazy používat.

Protože máme dva programy v jednom balíčku, spustíme konfiguraci %configure dvakrát a uděláme dvakrát. Pokud je balíček nakonfigurován pomocí autotools , pak makro %configure spustí konfigurační skript z kořene rozbaleného tarballu. Obvykle má mnoho parametrů, lze je zobrazit z příkazového řádku pomocí ./configure --help . Po %configure můžete zadat parametry, které potřebujete. Všimněte si, že volání %configure a ./configure se liší. V prvním případě se do konfigurátoru přenesou správné adresáře pro instalaci (stejně jako standardní parametry), ve druhém - výchozí adresáře.

Po úspěšné konfiguraci dojde k sestavení, konkrétně k makru %make, které zavolá stejnojmenný příkaz s některými dalšími parametry (zejména na víceprocesorových strojích se používá paralelní sestavení - možnost -j).

Pokud balíček nepoužívá autotools, pak %configure a možná %make není nutné používat; pro sestavení si přečtěte soubor README a INSTALL. ROSA má makra i pro jiné situace – například %cmake pro stejnojmenný nástroj pro sestavení.

Po úspěšném dokončení sestavení vstoupí v platnost sekce %install.

%install pushd %(name)-tools-%(version) %makeinstall_std popd %makeinstall_std %find_lang %(name)

%%find_lang , vyhledejte lokalizační soubory. Jeho parametrem je název souborů, které budou po instalaci umístěny v adresáři %(buildroot)/usr/share/locale/*/LC_MESSAGES/*.mo. To obvykle odpovídá %(name) . Pokud tomu tak není, napište jiné jméno.

V mnoha souborech specifikací si můžete všimnout, že příkaz rm -rf %(buildroot) nebo rm -rf $RPM_BUILD_ROOT se provádí na samém začátku sekce %install, stejně jako sekce %clean se stejnými řádky. V moderní ROSE to není potřeba, takové čištění se provádí automaticky.

%preun %preun_uninstall_gconf_schemas %(name)

Sekce pro instalační skripty. Obecně je jich několik. %pre - spuštěno před instalací, %post - po instalaci, %preun - před odstraněním, %postun - po odstranění. V našem příkladu odinstalace odstraní schémata Gconf. Zde předpokládáme, že v balíčku je pouze jedno schéma a jeho název je stejný jako název balíčku. Vezměte prosím na vědomí, že k odstranění schémat nazýváme speciální makro; toto makro je rozšířeno pomocí rpmbuild ROSA na sadu nezbytných příkazů Shell, které ve skutečnosti vymažou schéma. Instalace schémat při instalaci balíčku se provádí automaticky pomocí spouštěčů souborů RPM.

Každý balíček může mít své vlastní skripty, takže byste si měli přečíst také dokumentaci. Pokud pro správnou činnost nejsou potřeba žádné skripty, pak by tyto části neměly být používány. V těchto sekcích můžete použít bash skripty (stejně jako v jiných sekcích).

V sekcích %files musíme určit, které soubory mají být zabaleny. Všechny soubory musí být specifikovány, jinak rpmbuild ohlásí rozbalené soubory.

Volba -F je zadán soubor obsahující seznam zpracovaných souborů. V našem případě tento soubor obsahuje cesty k lokalizačním souborům. V zásadě si můžete vytvořit svůj vlastní soubor a vložit jej.

Pro definování adresářů se používají speciální definice maker.

• %(_prefix) - /usr
• %(_sysconfdir) - /etc
• %(_bindir) - /usr/bin
• %(_datadir) - /usr/share
• %(_libdir) - /usr/lib nebo /usr/lib64 v závislosti na bitové hloubce systému
• %(_lib) - /lib nebo /lib64
• %(_libexecdir) - /usr/libexec
• %(_includedir) - /usr/unclude
• %(_mandir) - /usr/share/man
• %(_sbindir) - /usr/sbin
• %(_localstatedir) - /var .
• %(systemd_libdir) - /usr/lib/systemd

%doc označuje soubory jako dokumentaci. Třetí řádek zkopíruje zadané soubory do katalogu %(_datadir)/doc/%(name)-%(version). Ve výchozím nastavení budou soubory v balíčku rpm vlastněny rootem a přístupová práva root budou stejná jako během procesu instalace. Pokud je to nutné změnit, použijte konstrukci %defattr.

%files tools %(_bindir)/stardict-editor

Totéž pro balíček stardict-tools. Pokud by se to jmenovalo tools-stardict , pak by %files vypadalo takto:

%files -n tools-%(name).

Poslední věcí v souboru spec je %changelog . V changelogu uvádíte změny v balíčku ve srovnání s předchozí verze. Jeho syntaxe je přibližně následující.

%changelog * Ne 22. dubna 2007 Vaše jméno - 2.4.8-4 - aktualizace záplaty pro plochu

Makro definice

Nyní je čas podívat se blíže na makra a proměnné. Řekněme, že vytváříme balíček ze SVN, in v tomto případě Vydání obvykle obsahuje datum revize. Na samém začátku souboru spec musíte definovat proměnnou data:

%definovat datum 20070612

Jak vidíme, makro definice %define je zodpovědná za definování proměnných. Nyní, kdekoli v souboru spec, můžeme použít naši proměnnou ve tvaru %(date) (závorky nejsou povinné, ale v ROSE je obvyklé dávat proměnné do hranatých závorek a nepřebírat definice maker; to usnadňuje rozlišovat mezi nimi). Například definování hlavních parametrů by vypadalo asi takto:

Verze: 0.5 Vydání: 0.svn%(datum).3

Upozorňujeme, že datu předchází 0. , a po datu - číslo, které se v případě potřeby zvyšuje pro zvýšení vydání. Proč se to dělá? Kdy konečně vyjde finální verze (v našem případě - 0.5 ), lze revizi odstranit a jednoduše zapsat do vydání 1 . Přitom doslovně 1 větší než kterýkoli řádek začínající 0 a balíček bude považován za novější než předběžné balíčky vytvořené z revizí SVN.

Extrémně oblíbenou makrodefinicí je konstrukce

%if podmínka akce1 %jiná akce2 %endif

nebo jen %if bez %else . Myšlenka je jednoduchá, pokud je podmínka v %if pravdivá, pak se provede akce1, jinak se provede akce2.

Řekněme, že zase něco sbíráme ze SVN. Obvykle uvnitř archivu, pokud je ze SVN, místo adresáře %(name)-%(version) jednoduše označují %(name) (archiv sim-0.9.5.tar.bz2 má uvnitř adresář sim, protože konečné vydání je sim 0.9.5 neexistuje. Finální vydání bude mít jako první adresář sim-0.9.5). Chcete-li se vyhnout pokaždé přepisování souboru spec, můžete vytvořit následující definice maker:

%define svn 1 ... %prep %if %(svn) %setup -q -n %(name) %else %setup -q %endif

Pokud proměnná svn není definována, provede se část skriptu za %else. Můžete také použít přísnější podmínku (nezapomeňte na uvozovky):

%define svn 1 ... %prep %if "%(svn)" == "1" %setup -q -n %(name) %else %setup -q %endif

Uvnitř všech sekcí souboru spec můžeme použít libovolné příkazy Linuxu bez jakýchkoli zvonků a píšťalek, ale v záhlaví souboru to není tak jednoduché. Například musíme definovat verze firefox pro balíček (řekněme epiphany) a přidejte jej do sekce Vyžaduje:. Bude to vypadat takto:

Vyžaduje: firefox = %(rpm -q firefox --qf "%%(verze)")

Vezměte prosím na vědomí, že externí příkaz se provádí v %() (téměř jako bash - $() ) a v souboru spec musíte do parametrů vložit dva znaky %. Tímto způsobem můžete volat libovolné příkazy Linuxu, například k určení verze jádra.

Další oblíbenou definicí makra je konstrukce %ifarch .. %endif. Pokud se architektura shoduje s architekturou zadanou po %ifarch , provede se nějaká akce. Architektury přicházejí v provedení i386, i486, i586, i686, i?86, x86_64 a samozřejmě některé další, se kterými se pravděpodobně nesetkáte.

Jak je uvedeno výše, ve všech částech souboru spec můžete použít jakékoli příkazy Shell, včetně for, while, if atd.

Sestavení balíčku

Nyní přejděme přímo k sestavení balíčku. Zdroje a opravy by měly být v adresáři SOURCES a soubor spec by měl být v adresáři SPECS. Poté musíte zadat příkaz:

Rpmbuild -ba spec soubor

Poté bude balíček sestaven (nebo nebude sestaven, ale vypadne s chybami) a binární balíčky se objeví v podadresářích adresáře RPMS a zdroj se objeví v adresáři SRPMS.

Velmi často, těsně před dokončením sestavení, rpmbuild zobrazí zprávu o nalezených, ale rozbalených souborech. To znamená, že jste je jednoduše nezahrnuli do sekce %files. Stačí je tam přidat. Pokud nechcete, aby byly tyto soubory součástí balíčku, můžete použít jednu z následujících metod:

• Přidejte definici makra do sekce %files

• Přidejte definici makra na začátek souboru spec

Pokud potřebujete sestavit pouze binární soubor nebo pouze zdroj, pak místo toho -ba by měl být použit -bb A -bs respektive. Mezi užitečné parametry rpmbuild můžeme poznamenat -čistý(odstraň všechny odpadky), -rmsource(odebrat zdroje z adresáře SOURCE) a -target=architektura(sestavit balíček pro konkrétní architekturu).

Skripty můžete také spouštět pouze v určité sekci. Takové parametry zde popisovat nebudeme, viz man rpm build.

Vytvoření balíčku RPM z balíčku již nainstalovaného v systému

Někdy se stane, že nějaký balíček je již v systému nainstalován (třeba ve velmi starém systému) a opravdu s ním chcete získat otáčky za minutu, ale prostě nebyl uložen. Můžete také chtít rychle sestavit balíček s konfiguračními soubory upravenými tak, aby vyhovovaly vašim potřebám.

Chcete-li tento problém vyřešit, měli byste použít nástroj rpmrebuild. Tento nástroj napsaný v bash je dostupný v úložišti ROSA contrib.

Práce s ním je velmi snadná. Stačí zadat příkaz:

Rpmrebuild nainstaloval název_balíčku

Pokud byl některý soubor změněn, budete o tom informováni, ale proces sestavení nebude přerušen.

Rpmrebuild má obrovské množství parametrů, můžete například změnit vydání balíčku, changelog, skripty, sekce Requires, popisy balíčků a mnoho dalšího. Můžete dokonce jednoduše změnit spec soubor, který si skript sám vygeneruje. Je pravda, že to bude trochu děsivé, ale pořád lepší než nic.

Všechny parametry lze zobrazit pomocí

Rpmrebuild --help