Gentoo ebuild - 7 (EAPI 1, QA kontroly, binární balíčky)

9. 4. 2008 | David Watzke

Články - Gentoo ebuild - 7 (EAPI 1, QA kontroly, binární balíčky)  

Co nového přináší EAPI 1? Jak na QA kontroly? Jak v ebuildu pracovat s RPM/DEB balíčky? Jak rozbalit různé typy archívů? V tomto díle naleznete odpovědi.

EAPI 1

Na EAPI může být nahlíženo jako na verzi specifikace, které daný ebuild odpovídá. EAPI 0 je základní verze, od které se budou odvíjet další verze.

Portage od verze 2.1.3.12 podporuje novou verzi EAPI (1), která rozšiřuje dosavadní možnosti ebuildů o několik užitečných věcí. Novou EAPI aktivujete přidáním EAPI="1" nahoru (hned pod hlavičku) do ebuildu. Předem ale zvažte zpětnou kompatibilitu, což platí především pro balíčky, na kterých závisí spousta jiných.

Závislost na slotu

Ebuildy mohou nově záviset na konkrétním slotu balíčku. Zápis do některé z proměnných *DEPEND vypadá takto:

sys-devel/automake:1.10

Tento příklad vyjadřuje závislost na balíčku sys-devel/automake se slotem 1.10.

IUSE může ovlivňovat výchozí nastavení USE

Nyní můžete ve svých ebuildech ovlivňovat výchozí nastavení USE flagů přidáním plus nebo mínus na jejich začátek. Jako příklad vezměme třeba textový editor nano:

IUSE="nls build +spell +justify debug slang ncurses +mac"

Pokud uživatelské nastavení USE (v /etc/make.conf) neobsahuje USE flag 'justify', tak jej Portage automaticky aktivuje.

Výchozí vypínání USE flagů (např. IUSE="-nocxx") sice nemá moc široké využití, vzhledem k tomu, že ve výchozím nastavení má (hned po USE nastavených jako proměnnou prostředí v běžícím shellu) nejnižší prioritu, nicméně funguje také.

Použití ECONF_SOURCE ve výchozí definici src_compile()

Toto malé vylepšení spočívá v tom, že je-li nastavena proměnná ECONF_SOURCE na adresář obsahující skript configure, tak jej econf použije místo hledání v aktuálním adresáři nyní i ve výchozí definici funkce src_compile(), kterou mimochodem není třeba předefinovávat, pokud v ní chcete spustit pouze econf a emake.

QA kontroly

Ebuildům je dostupných několik QA (quality assurance) proměnných, které umožňují ovlivňovat některé QA kontroly prováděné Portage. Používat by se měly naprosto minimálně, jinak budou popírat význam QA kontrol. V hlavním stromu se o jejich použití stará QA tým. Jsou primárně určeny k použití v ebuildech, které instalují uzavřené binární objekty, jež nelze měnit.

Pamatujte, že objekty, které porušují tato pravidla, mohou na některých architekturách selhávat.

Všechny následující proměnné lze nastavit na cesty k souborům relativně od adresáře image (např. /var/tmp/portage/app-office/openoffice-2.3.1-r1/image) můžou obsahovat regulární výrazy.

QA_TEXTRELS

Do této proměnné patří binární soubory, které obsahují text relocations a nelze je měnit. Jde například o closed-source objekty. Binárku s text relocations odhalí příkaz:

eu-readelf -d objekt.so | fgrep -q TEXTREL

Je-li návratová hodnota 0, znamená to, že objekt.so obsahuje text relocations.

QA_EXECSTACK

Sem patří binární objekty, které k běhu potřebují spustitelný zásobník. Ovšem opravdu jen ty a ne jen nějaké, které jsou tak označené a ve skutečnosti jej nepotřebují.

QA_WX_LOAD

Do této proměnné patří soubory, které obsahují zapisovatelné a spustitelné segmenty. Jsou docela vzácné.

Formáty zdrojových archívů

Funkce pro rozbalování unpack podporuje různé typy archívů, ale některé z nich vyžadují nástroje, které nejsou mezi systémovými závislostmi, a je tedy nutné na nich záviset v ebuildu (nevíte-li jak, vizte přechozí díl, konkrétně část "Závislosti potřebné k sestavení").

Formát	Závislost
ZIP/JAR	app-arch/unzip
RAR (*)	app-arch/unrar
LZMA (i tar.lzma)	app-arch/lzma-utils
7-Zip	app-arch/p7zip
LHa (lzh)	app-arch/lha

* RAR je sice podporovaný, ale co se týče hlavního stromu, tam pravděpodobně (možná z licenčních důvodů) na žádný nenarazíte. Na devmanual.gentoo.org se píše, že RAR archívy je nutné lokálně rozbalit a zaarchívovat do tar.bz2, nicméně v nějaké osobní overlayi to vadit nebude.

Binární balíčky

Někdy možná narazíte na closed-source software distribuovaný pouze v RPM a/nebo DEB balíčku. Ebuildy proto mají nástroje, které si s nimi poradí.

RPM

Nejdříve je třeba načíst si rpm.eclass pomocí inherit rpm. Pokud ve funkci src_unpack() nepotřebujete dělat (kromě rozbalení) nic dalšího (patchovat, mazat, přesouvat), není třeba ji definovat. Pokud ano, definice může vypadat následovně:

src_unpack() {
	rpm_src_unpack ${A}
	cd "${S}"

	# následuje váš kód:
	epatch "${FILESDIR}/${P}-gcc43-fix.patch"
}

Pokud máte v SRC_URI (a tím pádem i v ${A}) i archívy jiného typu než RPM, nemusíte to nijak řešit, rpm_src_unpack na ně zavolá obyčejný unpack.

Jsou dvě možnosti, jak rozbalit RPM: buď pomocí rpmoffset z balíku rpm2targz a cpio nebo pomocí rpm2cpio z balíku rpm. Obyčejně je pro rozbalování RPM balíku celá aplikace rpm kanón na vrabce, takže rpm2cpio se ve výchozím nastavení použije, pouze pokud je již nainstalován. Pokud chcete vynutit rozbalení pomocí rpmoffset, nastavte USE_RPMOFFSET_ONLY=1. Pokud naopak potřebujete použít rpm2cpio, přidejte balík app-arch/rpm jako závislost do proměnné DEPEND.

DEB

K DEB balíkům bývá dostupný zdrojový kód, takže to většinou není třeba řešit. Každopádně formát je to jednoduchý a lze jej spravovat pomocí programu ar z balíku binutils. Jelikož je tento balík systémová závislost, není třeba na něm záviset i v ebuildu. Podporuje jej unpack, takže není třeba (ani vhodné) spouštět přímo ar.

DEB balíky obsahují 3 soubory: debian-binary, což je textový soubor obsahující verzi formátu DEB; archív control.tar.gz obsahující pár souborů pro instalaci a kontrolu balíku; hlavní archív data.tar.gz, který obsahuje všechny zkompilované soubory a stačí jej jednoduše rozbalit (pomocí unpack), udělat případné změny (přesuny, atp.) a obsah přesunout do ${D}.

Seriál Gentoo ebuild (dílů: 8)

První díl: Gentoo ebuild - 1 (začínáme: názvy ebuildů a proměnné), poslední díl: Gentoo ebuild - 8 (EAPI 2).
Předchozí díl: Gentoo ebuild - 6 (závislosti, sloty, restrikce)
Následující díl: Gentoo ebuild - 8 (EAPI 2)