Obsah

Tvorba RPM/DEB balíčků
- RPM
- DEB
  - Finty
  - Tvorba

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:
1. 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í
2. 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ě.
3. 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.
4. 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

http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/

$ 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