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)

Diskuse k tomuto článku

[Jan Molič]

Díky za seriál! Vzhledem k tomu, že jsem si prošel různými source-distribucemi, můžu říct, že Portage je velmi silný nástroj, který je schopen zaktualizovat do současného stavu i stroje, na něž nebylo dva roky sáhnuto. V brzsku se nejspíš vrátím i na desktopu ke Gentoo, protože už jsem si dostatečně užil pohodlí *buntu

[Marián Kyral]

K čemu je dobré to výchozí nastavení USE? Jen k tomu, abych více používal package.use?

[David Watzke]

Proč bys měl více používat package.use? USE, na kterých ti záleží, si nastavíš v hlavním konfigu a tohle tě pak ani nemusí moc trápit. Díky tomu vývojáři mohou nastavit rozumné výchozí hodnoty nejen globálně, ale i pro jednotlivé ebuildy.

[Marián Kyral]

Use které chci si nastavím globálně, ale pokud to začnou vývojáři zneužívat, tak se obávám, že toho budu vypínat více, než když je teď vše vypnuté a já jen občas něco povolím.

[David Watzke]

To je teda zvláštní pohled na věc, ale prosím.

[petr_p]

Možná zvláštní, ale nemá jej sám. Už jsem taky supěl u MPlayeru, co to mají za nápady:

+a52 -aalib +alsa -arts -color -console -cflags +dvd -fbcon -gif -jpeg -libcaca +mad -md5sum +mmx +mp3 +vorbis -png -pnm -rar -samba +theora -tivo +truetype +X +xscreensaver +xv

[Jan Kundrát (jkt)]

Chapu, ze je to naprosto neuveritelne, ale pomerne dost lidi si rado film pusti i s ozvucenim (+alsa), prehrava DVDcka (+dvd), pripadne ten mplayer pousteji pod Xkama.

[petr_p]

…pomerne dost lidi si rado…

To je přesně ten problém. Tímto způsobem za chvíli budeme mít zavšivený systém tunami knihoven a rozšířeními, které nikdy nepoužijeme.

Já např. DVD mechaniku nemám, přes -vo x11 si také video nepřehrávám, mad neptřebuju, když tu samou funkcionalitu mám ve ffmpegu, obrazovku zamykám, když chci já, a DPMS umí vypnout mplayer sám o sobě bez xscreensaver knihovny atd.

[David Watzke]

Výborně, tak si to vypni. To bys úplně stejně mohl nadávat na make.defaults a to je přece hloupost.

[petr_p]

Mohl bych nadávat a už jsem tak pár krát pro sebe učinil :(

Hloupost to není. Když mám default-linux/x86, tak jsem se domníval, že systém bude skutečně minimální a já si vlastnoručně zapnu, co budu potřebovat. A ne že budu po vývojářích vypínat, co oni považují za běžnou věc.

Problém pkgintenrnal flagů je, že jsou často lokální, a ty do /etc/make.conf nepatří. Takže jejich inhibování pěkně leze na nervy. Doufám, že se správci budou krotit, jinak jim svůj package.use omlátím o hlavu ;)

[qk_]

no mne se to moc nelibi, ale obrana pomerne jednoducha -* a povolit jen co chci..ale je fakt ze u deprecated je to obcas opruz kdyz neco zavisi na tomhle USE flagu

[Elch]

Dobré, jako vždy :)

[Jan Kundrát (jkt)]

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 /etc/env.d/) nejnižší prioritu, nicméně funguje také.

Tohle je trosku zavadejici -- promenne prostredi se berou z prostredi shellu, ze ktere ho poustis emerge, ne z nejakeho adresare na disku. Je sice pravda, ze .bashrc je nacita z /etc/profile, ktery ve vysledky sourcuje nejaky soubor vznikly z /etc/env.d/*, ale to neznamena, ze by portage pracovalo s /etc/env.d/. Mysleny jsou promenne definovane jako treba `USE="-X" emerge mplayer`.

[Luboš Doležel (Doli)]

Díky, opraveno.