Gentoo ebuild - 5 (problémy, sandbox, kontrolní součty)

16. 4. 2007 | David Watzke | Návody | 4790×

Tento díl je o sandboxu (používaném pro některé fáze testování), kontrolních součtech a běžných problémech, se kterými se patrně občas setkáte.

QA oznámení

Ve skriptu ebuild.sh, který je nedílnou součástí Portage, jsou různé kontroly běžných problémů, které mohou způsobit vypsání hlášky začínající na „QA Notice“. V této části článku se dozvíte, jak takové problémy řešit.

USE Flag foo not in IUSE

Hláška vás upozorňuje, že jste zapomněli vypsat do proměnné ${IUSE} všechny USE flagy, které v ebuildu používáte. Výjimkou jsou flagy architektur a proměnné vyjmenované v ${USE_EXPAND}, která je nastavena od Portage verze 2.0.51.20 v ${PORTDIR}/profiles/base/make.default — ty do ${IUSE} nepatří, Portage si s nimi poradí sama.

command in global scope

Žádný externí kód by neměl být spouštěn v globálním rozsahu. Pokud ovšem byl takto spuštěn, objeví se tato hláška. V závislosti na tom, o co se snažíte, je vhodné použít některé z alternativ.

sed, awk, grep, egrep, cut, atp.

Tyto nástroje se v globálním rozsahu často používají k úpravě řetězce s verzí nebo názvem programu. Je dobré se jim vyhýbat a používat buď substituci Bashe, anebo funkce z eclass versionator (vizte man versionator.eclass, je třeba mít nainstalované portage-manpages), které tuto substituci zjednodušují.

has_version, best_version, portageq

Ke globálnímu volání těchto funkcí by nemělo nikdy dojít. Nesmíte mít metadata lišící se od systému. Pokud na tuto hlášku narazíte v souvislosti s těmito příkazy, pak byste měli přepsat váš ebuild tak, aby správně používal závislosti — podmiňované nastavování proměnné ${DEPEND} je přípustné jen tehdy, když závisí pouze na statických proměnných obsahujících název programu a verzi (P, PN, PV, PR, PVR a PF).

python, perl

Ebuildy jsou skripty v Bashi a používání jiného jazyka jen proto, že jistou věc neumíte napsat v Bashi, je nepřípustné — přinejmenším proto, že uživatelé nemusí mít vždy při sourcování ebuildu kompletní systém.

foo is setXid, dynamically linked and using lazy bindings

Dynamicky linkované setXid aplikace by z bezpečnostních důvodů neměly používat lazy bindings (tj. když program začne hledat funkci v knihovnách, až když je zapotřebí) při linkování. Pokud na toto narazíte, máte tyto možnosti:

• Upravit (opatchovat) Makefile (nebo ekvivalent) balíčku tak, aby při linkování používal přepínače -Wl,-z,now. To je upřednostňované řešení.
• Načíst si eclass flag-o-matic a použít funkci append-ldflags. Toto ovšem ovlivní všechny binárky, nejen setXid.

ECLASS foo inherited illegally

Tato hláška vám sděluje, že načítáte eclass nesprávným způsobem. Všechny eclass (i když funkci z některé potřebuje např. jen jedna architektura), které v ebuildu/eclass načítáte, musí být načteny vždy — existuje výjimka a je stejná jako u proměnné ${DEPEND}, vizte výše. Můžete použít například toto:

if [[ "${PN##*-}" == "cvs" ]] ; then
	inherit cvs
fi

Sandbox

Portage používá sandbox pro některé fáze sestavování. Dělá to proto, aby zabránila neoprávněnému zápisu mimo dočasný adresář, kde se kompiluje.

Když se balík pokusí o něco, co se sandboxu nelíbí, tak se kompilace přeruší a vypíše se chybová hláška s podrobnostmi.

-------------- ACCESS VIOLATION SUMMARY -------------
LOG FILE = "/tmp/sandbox-kategorie_-_balik-1.0-31742.log"

open_wr:   /nejaky/soubor
-----------------------------------------------------

Kupříkladu open_wr znamená, že došlo k pokusu o otevření souboru pro zápis.

K těmto chybám dochází logicky nejčastěji při instalaci. Když Makefile respektuje proměnnou DESTDIR, potom je to jednoduché a můžete použít:

emake DESTDIR="${D}" install

nebo případně make, pokud paralelní instalace s emake selže. Když to nefunguje, můžete zkusit ještě einstall (bez argumentů), ale ten opravdu jen když první způsob nejde. No a když nejde ani tohle, tak zřejmě budete muset upravit Makefile vy sami a vytvořit si patch (případně použít sed, jde-li o triviální změnu). Pokud se Makefile generuje, ať už pomocí autotools nebo čehokoliv jiného, potom upravte přímo ten soubor, ze kterého se generuje. Oprava většinou nebývá nijak moc složitá a když se vám povede, můžete ji zaslat vývojářům daného programu, kteří ji pak mohou začlenit do dalších verzí.

K dispozici je několik funkcí pro ovládání a ladění sandboxu. Nepoužívejte je pro řešení problémů, za které může špatný Makefile.

addread	Přidá právo pro čtení.
addwrite	Přidá právo pro zápis.
adddeny	Zakáže zápis.
addpredict	Předstírá právo zápisu.

Poznámky:

• Používání addwrite není správným způsobem jak řešit problémy se sandboxem, proto pokud možno používejte addpredict.
• Všechny tyto funkce berou jako argument jednu položku.
• Sandbox je rekurzivní, takže pro předstíraný zápis do /neco/aaa a /neco/bbb stačí spustit addpredict /neco.

Občas může dojít k pokusu o zápis do ${HOME}. V takovém případě je vhodné využít proměnné ${T} a zapisovat tam. Ukázkový příklad je k vidění v ebuildu fluxboxu, který tak řeší generování menu.

ebegin "Creating a menu file (may take a while)"
mkdir -p "${T}/home/.fluxbox" || die "mkdir home failed"
MENUFILENAME="${S}/data/menu" MENUTITLE="Fluxbox ${PV}" \
	CHECKINIT="no. go away." HOME="${T}/home" \
	"${S}/util/fluxbox-generate_menu" -is -ds \
	|| die "menu generation failed"
eend $?

Kontrolní součty

Když napíšete ebuild, před jeho instalací je nutné (poprvé a pak s každou změnou v ebuildu, zdrojácích, patchích, atp.) vytvořit soubor s kontrolními součty (MD5, RMD160 a SHA256). Je to nutné z bezpečnostních důvodů. Soubor se například přenese poškozený, nebo je zmetek už na mirroru, atp. Existuje několik způsobů, jak tyto kontrolní součty vytvořit. Běžně se používá:

ebuild balicek-1.0.ebuild digest

Ale pokud chcete rovnou instalovat, můžete použít:

emerge --digest =balicek-1.0

Projde i zadání cesty k ebuildu, ale to patrně (podle hlášky, co na vás vyskočí) nemusí vždy fungovat, tak to raději nepoužívejte.

emerge --digest balicek-1.0.ebuild

Dalším způsobem téhož je:

FEATURES=digest emerge =balicek-1.0

Nebo můžete zadat cestu, ale platí totéž, co jsem psal kousek výš:

FEATURES=digest emerge balicek-1.0.ebuild

       

Komentáře

[Jan Kundrát (jkt)]

"Portage si s nimi poradí sama." -- "ta" Portage? Neni to spis "to"?

"Nesmíte mít metadata lišící se od systému." -- cestejsi by bylo spis "metadata daneho ebuildu nesmi zaviset na prostredi systemu, kde portage pracuje".

"ebuild digest" -- nepletu li se, prechazi se na "ebuild manifest", lec s ebuildy nepracuju a tak se mozna pletu.

[Robert Krátký]

"Portage si s nimi poradí sama." -- "ta" Portage? Neni to spis "to"?

Podle čeho soudíš? Já si také nejsem jistý, tak jsem to ponechal na autorovi. Mně by zase nejrozumnější připadal mužský rod (balíčkovací systém Portage).

"Nesmíte mít metadata lišící se od systému." -- cestejsi by bylo spis "metadata daneho ebuildu nesmi zaviset na prostredi systemu, kde portage pracuje".

Tvůj přepis má IMO jiný význam.

[Jan Kundrát (jkt)]

"Portage si s nimi poradí sama." -- "ta" Portage? Neni to spis "to"?

Podle čeho soudíš? Já si také nejsem jistý, tak jsem to ponechal na autorovi. Mně by zase nejrozumnější připadal mužský rod (balíčkovací systém Portage).

Podle "bezne terminologie" na ceskem ML a IRC; domnivam se, ze je "to" o neco beznejsi. Dotaz byl smerovan spise na autora nez na korektora.

"Nesmíte mít metadata lišící se od systému." -- cestejsi by bylo spis "metadata daneho ebuildu nesmi zaviset na prostredi systemu, kde portage pracuje".

Tvůj přepis má IMO jiný význam.

Ano, ma jiny vyznam, to bylo cilem opravy :). Ebuild si "sam od sebe" nesmi menit graf zavislosti, napr. na zaklade v systemu nainstalovanych balicku. Jednim z duvodu je treba to, aby se dala jedna kopie Portage tree pouzit na vice strojich.

[David Watzke]

"Portage si s nimi poradí sama." -- "ta" Portage? Neni to spis "to"?

To mi přijde divný, ale především je to jedno

"Nesmíte mít metadata lišící se od systému." -- cestejsi by bylo spis "metadata daneho ebuildu nesmi zaviset na prostredi systemu, kde portage pracuje".

Tak nějak je to ale myšleno... no, uznávám, že tvoje verze je jasnější...

"ebuild digest" -- nepletu li se, prechazi se na "ebuild manifest", lec s ebuildy nepracuju a tak se mozna pletu.

manifest jsem ani neznal, ale podle manuálu jde o něco krapet jiného:

digest
	Creates a digest file for the package
	in /usr/portage/[category]/[package]/files/. 
	This digest file lists the md5sums  of  all
	the files found in the SRC_URI.  If the fetched
	source of the package is corrupt/bogus in some way,
	the md5sum will catch this.

manifest
	Updates the manifest file for the package.
	This performs the second half of the digest
	command, creating md5sums for the files in the
	files directory as well as the ebuild.

[Jan Kundrát (jkt)]

Tak podle GLEPu 44 mam pravdu, digesty jsou prekonany manifestem :).

[Luboš Doležel (Doli)]

Jinak než "ta Portage" to nikdy neřeknu

[~||~]

Anglicka slova se v cestine mohou sklonovat libovolne, protoze CZ pravidla pro ne neplati. Tedy spravne to piseme vsichni (ten portage, ta portage, to portage, ty portage).

[egg]

Já bych psal ta portáž. Ale neberte mě vážně, protože mám ve zvyku číst broken packages jako zlámaná pakáž.

[Gilhad]

já zase čtu ten portydž podle vzoru ten porydž