packaging
Toto je starší verze dokumentu!
Obsah
Tvorba RPM/DEB balíčků
RPM
- je potřeba vytvořit .spec soubor
- je potřeba spustit rpmbuild a mít připravené prostředí
- úplně základní informace zde
- rpmbuild potřebuje buildovací prostředí (většinou v cestě /usr/src/redhat, nebo nekdy ~/rpmbuild)
- SPECS - obsahuje spec-soubory, které řídí vlastní sestavování RPM balíku.
- SOURCES - zde jsou zdrojové soubory, ze kterých se balík vytváří (zpravidla tar.gz)
- BUILD - do tohoto adresáře se rozbalí zdrojové soubory a probíhá zde kompilace.
- RPMS/architektura - sem se uloží výsledné RPM soubory.
- SRPMS - zde budou výsledné zdrojové RPM soubory.
- prostředí lze předefinovat pomocí proměných například v konfiguračním souboru
$ cat ~/.rpmmacros
%_topdir /home/jamatos/
%_tmppath /tmp/rpmbuild
%_builddir %{_tmppath}
%_rpmtopdir %{_topdir}/build/%{name}
%_sourcedir %{_rpmtopdir}
%_specdir %{_rpmtopdir}
%_rpmdir %{_rpmtopdir}
%_srcrpmdir %{_rpmtopdir}
- nebo parametrem programu rpmbuild
rpmbuild --buildroot="${BUILDDIR}/rpm-root" \ --define="_builddir ${BUILDDIR}/BUILD" \ --define="_rpmdir ${BUILDDIR}/RPMS" \ --define="_tmppath ${BUILDDIR}/rpm-tmp" \ --define="_sourcedir ${BUILDDIR}/SOURCES" \ -bb "${BUILDDIR}/$1.spec"
- seznam proměnných/maker zde
spec file
- SourceX
- soubor balíčku zadaný jako URL nebo název souboru v SOURCES adresáři, typicky tgz archív se zdrojáky
- X zastupuje číslo, například Source0, Source1.., může jich být tedy více
- Source bez čísla je synonymum k Source0
- lze využít proměnné %{name}, %{version}
- PatchX
- rozdílový soubor zadaný jako URL nebo název souboru v SOURCES adresáři, typicky obsahující modifikace souborů z archívu SourceX
- X zastupuje číslo, například Patch0, Patch1.., může jich být tedy více
- Requires
- na čem balíček závisí
- například názvy jiných balíčků oddělených čárkou
- lze zadat i konkrétní verze přes komparátory (<,>,
- %prep
- příkazy k přípravě balíčku
- typicky volají příkaz setup, který zařídí extrakci souborů SourceX
- setup má parametry, popis například zde
- setup lze nahradit například zápisem
cd %{_builddir}
rm -rf %{name}-%{version}
cp -rf %{_sourcedir} %{name}-%{version}
cd %{name}-%{version}
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
- %build
- příkazy pro build programu, který balíček reprezentuje
- pokud nic buildovat nepotřebujeme, tak lze sekci vynechat
- %install
- příkazy pro instalaci, typicky kopírování z %{_builddir} do %{buildroot}, který reprezentuje cílový kořenový adresář.
- %pre - příkazy před instalací/upgrade
- %post - příkazy po instalaci/upgrade, nesmí končit nenulově
- %preun - příkazy před odinstalací
- %postun - příkazy po odinstalování, nesmí končit nenulově
| install | upgrade | uninstall | |
|---|---|---|---|
| %pretrans | $1 == 0 | $1 == 0 | (N/A) |
| %pre | $1 == 1 | $1 == 2 | (N/A) |
| %post | $1 == 1 | $1 == 2 | (N/A) |
| %preun | (N/A) | $1 == 1 | $1 == 0 |
| %postun | (N/A) | $1 == 1 | $1 == 0 |
| %posttrans | $1 == 0 | $1 == 0 | (N/A) |
%post case $1 in 1) # instalation ;; 2) # upgrade ;; esac
- %files
- soubory, které budou balíčkem instalovány (verzovány)
- všechny soubory vytvořené v
%{buildroot}musí být vypsány ve sekci%files, jinak balíček nelze vytvořit - místo souborů lze použít hvězdičku
- pozor na verzování obecných adresářů, může vytvořit konflikt s jinými balíčky
- souborům lze nastavit oprávnění a vlastníka předřazením
%attr(644,user,group)před název souboru - konfigurační soubory by měly mít předřazeno označení
%config(případně i před%attr)- pokud je v balíčku novější cfg soubor, tak přepíše lokální a případné modifikace lokálního uloží do .rpmsave
Příklad "rychle na prasáka"
- mám složku se zdrojáky s fungujícím ./configure + make
- chci udělat jednou jeden binární balíček
- jako uživatel mám omezené oprávnění, nemůžu zapisovat do /usr/src/redhat
- vytvořím .spec soubor
Summary: Balicek na rychlo
Name: balicek-prvni
Version: 1.0
Release: 0
Source: none
License: GPL
Group: Utilities/System
%description
Tohle je muj balicek
%prep
%build
%configure
make OPTIM="$RPM_OPT_FLAGS"
%install
%makeinstall PREFIX=$RPM_BUILD_ROOT install
%files
%{_bindir}
%{_datadir}
- do sekce files je potřeba vypsat všechny soubory, které se přidaly voláním make install. Lze použít uvedená makra
- spuštění tvorby baličku
BASEDIR=`pwd`
mkdir -p build/{root,BUILD}
cp -ra projekt/* build/BUILD/
chmod +x build/BUILD/configure
rpmbuild --buildroot=${BASEDIR}/build/root --define="_builddir ${BASEDIR}/build/BUILD" --define="_rpmdir ${BASEDIR}/build/" -bb balicek-prvni.spec
- výsledné rpm najdu ve složce build
Příklad "na slušňačku"
- příklad jednoduchého spec
Summary: Bblablablabla
Name: balicek-prvni
Version: 1.0
Release: 0
Source: projekt-src.tar.gz
Copyright: GPL
Group: Utilities/System
%description
Tohle je muj balicek
%prep
%setup
%build
make OPTIM="$RPM_OPT_FLAGS"
%install
make PREFIX=$RPM_BUILD_ROOT install
%files
%{_bindir}
%{_datadir}
- zapojení do Makefile
# pripravi adresarovy strom a nastaveni pro RPM
rpmbuildenv:
mkdir -p ~/rpmbuild/{BUILD,RPMS/x86_64,SOURCES,SPECS,SRPMS}
(echo "%_topdir ~/rpmbuild";echo "%_prefix /usr/local/") >> ~/.rpmmacros
rpm:
cp -ra zdrojaky zdrojaky-tmp
chmod +x zdrojaky-tmp/configure
# odstraneni info o svn, pokud tam je
find zdrojaky-tmp -name '.svn'|xargs rm -rf
tar czf zdrojaky-tmp.tgz zdrojaky-tmp
# pokud je lokalni RPM build prostredi tak do nej supnu balicky a spec file (dodelat)
[ -d ~/rpmbuild/SOURCES ] && cp -f zdrojaky-tmp.tgz ~/rpmbuild/SOURCES
all: rpmbuildenv rpm
jak probiha upgrade
Hence, the order of operations during an upgrade is:
- Run the %pre section of the RPM being installed.
- Install the files that the RPM provides.
- Run the %post section of the RPM.
- Run the %preun of the old package.
- Delete any old files not overwritten by the newer version. (This step deletes files that the new package does not require.)
- Run the %postun hook of the old package.
A taky pozor na instalaci vice balicku najednou, chova se to trochu jinak. Hromadny upgrade (rpm -Uvh *) nejspis funguje takto:
- a) u vsech balicku spusti pre-install
- b) u vsech balicku provede install
- c) u vsech balicku spusti post-install
- *) pak se teprve dela pre/post uinstall
Pořadí, ve kterém se bude spouštět pre-install není asi dopředu známo. Pokud jsou balíčky závislé na sobě, je dobré využít trigger skripty (%triggerin, %triggerun, %triggerpostun)
https://fedoraproject.org/wiki/Packaging:Scriptlets
- %pretrans of new package
- %pre of new package
- (package install)
- %post of new package
- %triggerin of other packages (set off by installing new package)
- %triggerin of new package (if any are true)
- %triggerun of old package (if it's set off by uninstalling the old package)
- %triggerun of other packages (set off by uninstalling old package)
- %preun of old package
- (removal of old package)
- %postun of old package
- %triggerpostun of old package (if it's set off by uninstalling the old package)
- %triggerpostun of other packages (if they're setu off by uninstalling the old package)
- %posttrans of new package
malé velké rady
- post skripty nesmí failovat!! balíček je už totiž nainstalovaný. Pokud balíček přeci jen skončí s fail, zůstavají v systému dvě verze balíčku. Musí se to opravit ručně.
- navratová hodnota posledního příkazu v post/pre skriptech se bere jako návratová hodnota celého skriptu. Nejlepší je tam psát exit 0 jako pojistku
distribuce dočasných install souborů
- Narazil jsem na problém. Mám rpm balíček pro aplikaci, která potřebuje v databázi určitá schémata. Mám skript a soubor s sql importem. Jak to správně zabalíčkovat? Skript i sql soubory potřebuji jen pro instalaci, pak už ne.
- RPM na tento problém nemá ideální řešení. Možnosti jsou:
- vložit skript a sql přímo do .spec souboru (třeba do %pre). Velikost spec souboru je limitovaná!! Navíc se ukládá do rpm databáze, takže to u větších skriptů/sql není ideální
- při buildu balíčku naimportovat sql do databáze a distribuovat pak binární soubor databáze. Tohle řešení lze ale použít jen pro čistý install. Upgrade se pak řeší komplikovaně.
- dedikovat na cílovém stroji adresář pro skripty/sql. Soubory tam normálně nahrát přes %files. Soubory se nesmí smazat, aby nevzniknul problém. Tohle je asi nejlepší varianta.
- označit dočasné soubory ve %files jako %config(missingok). Po použití je lze smazat. Není to ale úplně správné řešení, protože se config se správně používá jen pro konfigurační soubory
zdroje:
DEB
Finty
- nalezení balíčku, který obsahuje soubor
$ dkpg -S /bin/cat coreutils: /bin/cat
- Jak zobrazit dostupnou a nainstalovanou verzi?
# apt-cache policy gnome-control-center
gnome-control-center:
Instalovaná verze: 1:2.20.0-1
Kandidát: 1:2.20.0-1
Tabulka verzí:
*** 1:2.20.0-1 0
500 ftp://ftp.cz.debian.org unstable/main Packages
100 /var/lib/dpkg/status
Tvorba
$ mkdir -p ./debian/usr/bin $ cp linuxstatus ./debian/usr/bin
Package: linuxstatus Version: 1.1-1 Section: base Priority: optional Architecture: all Depends: bash (>= 2.05a-11), textutils (>= 2.0-12), awk, procps (>= \ 1:2.0.7-8), sed (>= 3.02-8), grep (>= 2.4.2-3), coreutils (>= 5.0-5) Maintainer: Chr. Clemens Lee <clemens@kclee.de> Description: Linux system information This script provides a broad overview of different system aspects.
$ mkdir -p debian/DEBIAN $ find ./debian -type d | xargs chmod 755 # this is necessary on Debian Woody, don't ask me why $ cp control debian/DEBIAN
$ dpkg-deb --build debian dpkg-deb: building package `linuxstatus' in `debian.deb'. $ mv debian.deb linuxstatus_1.1-1_all.deb
packaging.1623136998.txt.gz · Poslední úprava: (upraveno mimo DokuWiki)
