Gentoo Linux alpha Kézikönyv: Munka a Gentoo operációs rendszerrel

Üdvözli Önt a Portage szoftvercsomag-kezelő!

A Gentoo egyik legfigyelemreméltóbb újítása a szoftverkezelés téren a Portage szoftvercsomag-kezelő. Magas fokú rugalmasságával és rengeteg funkciójával gyakran a Linuxra elérhető legjobb szoftverkezelőként tartják számon.

A Portage szoftvercsomag-kezelő teljes mértékben Python-ban és Bash-ben íródott, ezért teljes mértékben látható a felhasználók számára, mivel mindkettő szkriptnyelv.

A legtöbb felhasználó az emerge eszközön keresztül fog dolgozni a Portage szoftvercsomag-kezelővel. Ez a fejezet nem szándékozik ismételni az emerge man súgó oldalán elérhető információkat. Az emerge lehetőségeinek teljes körű áttekintéséhez kérjük, tekintse meg a man súgóoldalt:

user $man emerge

Gentoo szoftvercsomag-tároló

Ebuild-ek

Amikor a Gentoo dokumentációja szoftvercsomagokról beszél, azokat a szoftvereket érti ez alatt, amelyek a Gentoo felhasználók számára elérhetőek a Gentoo szoftvercsomag-tárolóján keresztül. Ez a szoftvercsomag-tároló egy gyűjtemény ebuilds-ekből, fájlokból, amelyek tartalmazzák az összes információt, amire a Portage szoftvercsomag-kezelőnek szüksége van a szoftver karbantartásához (telepítés, keresés, lekérdezés stb.). Ezek az ebuilds-ek alapértelmezés szerint a /var/db/repos/gentoo könyvtárban találhatóak meg.

Amikor valaki megkéri a Portage szoftvercsomag-kezelőt, hogy hajtson végre valamilyen műveletet a szoftverekkel kapcsolatban, akkor az az operációs rendszerünkön található ebuilds-eket használja alapként. Ezért fontos, hogy rendszeresen frissítsük a operációs rendszerünkön található ebuilds-eket, hogy a Portage szoftvercsomag-kezelő tudjon az új szoftverekről, biztonsági frissítésekről stb.

Gentoo szoftvercsomag-tároló frissítése

A Gentoo szoftvercsomag-tárolót általában rsync segítségével frissítik, amely egy gyors, növekményes fájlátviteli segédprogram. A frissítés viszonylag egyszerű, mivel a emerge parancs front-end felületet biztosít az rsync számára:

root #emerge --sync

Néha tűzfal-korlátozások lépnek életbe, amelyek megakadályozzák, hogy az rsync kapcsolatba lépjen a tükörszerverrel. Ilyen esetben a Gentoo szoftvercsomag-tárolót napi generált pillanatképek segítségével lehet frissíteni. Az emerge-webrsync eszköz automatikusan letölti és telepíti a legfrissebb pillanatképet a rendszerre:

root #emerge-webrsync

Szoftver karbantartása

Szoftver keresése

Többféle módon is lehet szoftvert keresni a Gentoo szoftvercsomag-tárolóban. Az egyik mód az emerge parancs segítségével történik. Alapértelmezés szerint az emerge --search visszaadja azoknak a szoftvercsomagoknak a nevét, amelyeknek a címe teljesen vagy részben egyezik a megadott keresési kifejezéssel.

Például, annak érdekében, hogy megkeresse az összes olyan szoftvercsomagot, amelynek a nevében szerepel a "pdf" kifejezés, futtassa a következő parancsot:

user $emerge --search pdf

A szoftverleírásokban történő kereséshez használja a --searchdesc (vagy -S) opciót:

user $emerge --searchdesc pdf

Vegye figyelembe, hogy a kimenet sok információt tartalmaz. A mezők egyértelműen vannak címkézve, így nem fogunk belemenni a jelentésükbe:

CODE Példa kimenet egy keresési parancshoz

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Szoftver telepítése

Amikor a szoftver címe meg lett találva, akkor a telepítés csak egy emerge parancsnyira van tőlünk. Például a gnumeric telepítéséhez futtassa a következő parancsot:

root #emerge --ask app-office/gnumeric

Mivel sok alkalmazás függ egymástól, ezért egy bizonyos szoftvercsomag telepítésére tett kísérlet több szoftver telepítését is eredményezheti függőség gyanánt. Ne aggódjon, a Portage jól kezeli a függőségeket. Ahhoz, hogy megtudja, milyen szoftvercsomagokat telepítene a Portage, adja hozzá a --pretend opciót. Például:

root #emerge --pretend gnumeric

A --ask kapcsoló hozzáadásával pedig Ön interaktív módon döntheti el, hogy valóban folytatni akarja-e a telepítést:

root #emerge --ask gnumeric

Egy szoftvercsomag telepítése során a Portage letölti a szükséges forráskódot az internetről (ha szükséges), és alapértelmezés szerint a /var/cache/distfiles/ könyvtárban tárolja. Ezután a szoftvercsomagot kicsomagolja, lefordítja bináris futtatható kódra és telepíti azt. Ha csak a forráskódokat szeretné letölteni anélkül, hogy telepítené őket, adja hozzá a --fetchonly opciót az emerge parancshoz:

root #emerge --fetchonly gnumeric

Telepített szoftvercsomagok dokumentációjának a keresése

Számos szoftvercsomag saját dokumentációval érkezik. Néha a doc USE jelölőzászló határozza meg, hogy a szoftvercsomag dokumentációját telepíteni kell-e vagy sem. Annak megállapításához, hogy egy szoftvercsomag használja-e a doc USE jelölőzászlót, használja az emerge -vp kategória/szoftvercsomagnév parancsot:

root #emerge -vp media-libs/alsa-lib

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild   R    ] media-libs/alsa-lib-1.1.3::gentoo  USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB

A legjobb módja a doc USE jelölőzászló engedélyezésének az, ha szoftvercsomagonként teszi meg a /etc/portage/package.use fájlban, hogy csak a szükséges szoftvercsomagok dokumentációja legyen telepítve. További információkért olvassa el a USE jelölőzászlók részt.

Miután a szoftvercsomag telepítve van, a dokumentációja általában a szoftvercsomagról elnevezett alkönyvtárban található a /usr/share/doc/ könyvtárban:

user $ls -l /usr/share/doc/alsa-lib-1.1.3

total 16
-rw-r--r-- 1 root root 3098 Mar  9 15:36 asoundrc.txt.bz2
-rw-r--r-- 1 root root  672 Mar  9 15:36 ChangeLog.bz2
-rw-r--r-- 1 root root 1083 Mar  9 15:36 NOTES.bz2
-rw-r--r-- 1 root root  220 Mar  9 15:36 TODO.bz2

Egy biztosabb módja az telepített dokumentációs fájlok felsorolásának az equery --filter opció használata. Az equery a Portage adatbázisának lekérdezésére szolgál, és a app-portage/gentoolkit szoftvercsomag részeként érkezik:

user $equery files --filter=doc alsa-lib

 * Searching for alsa-lib in media-libs ...
 * Contents of media-libs/alsa-lib-1.1.3:
/usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2
/usr/share/doc/alsa-lib-1.1.3/NOTES.bz2
/usr/share/doc/alsa-lib-1.1.3/TODO.bz2
/usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2

A --filter opció más szabályokkal együtt használható más típusú fájlok telepítési helyeinek megtekintéséhez. A további funkcionalitás az equery man súgójában található: man 1 equery.

Szoftver eltávolítása

A szoftver biztonságos eltávolításának érdekében használja az emerge --deselect parancsot. Ez megmondja a Portage szoftvercsomag-kezelőnek, hogy a szoftvercsomagra már nincs szükség, és jogosult a --depclean opcióval történő tisztításra.

root #emerge --deselect gnumeric

Amikor egy szoftvercsomag már nincs kiválasztva, a szoftvercsomag és annak szoftverfüggőségei, amelyek automatikusan lettek telepítve a szoftvercsomag telepítésekor, még mindig az operációs rendszerünkön maradnak. Ahhoz, hogy a Portage megtalálja az összes szoftvercsomag függőséget, amelyeket most már el lehet távolítani, használja az emerge --depclean funkcióját, amely később kerül dokumentálásra.

Operációs rendszerünk frissítése

Az operációs rendszerünk tökéletes állapotban tartása érdekében (és nem utolsósorban a legújabb biztonsági frissítések telepítése miatt) szükséges az operációs rendszer rendszeres frissítése. Mivel a Portage csak a Gentoo szoftvertároló ebuild-jeit ellenőrzi, az első lépés a gépünkre korábban letükrözött szoftvertároló felfrissítése az emerge --sync használatával. Ezután az operációs rendszert az emerge --deep --update @world parancs használatával lehet frissíteni:

A --deep opcióval a Portage újabb verziókat keres a telepített alkalmazásokhoz. Enélkül a Portage csak az explicit módon telepített alkalmazások (az /var/lib/portage/world fájlban felsorolt alkalmazások) verzióit ellenőrzi - nem ellenőrzi alaposan a függőségeiket. Ezért ezt az opciót szinte mindig használni kell:

root #emerge --update --deep @world

A standard frissítési parancsnak tartalmaznia kell a --changed-use vagy a --newuse opciót a szoftvertároló profiljában történt lehetséges változások miatt, vagy ha a rendszer USE beállításai módosultak. A Portage ekkor ellenőrzi, hogy a változás új szoftvercsomagok telepítését vagy meglévők újrafordítását igényli-e:

root #emerge --update --deep --newuse @world

Meta szoftvercsomagok

Néhány szoftvercsomagnak a Gentoo szoftvercsomag-tárolóban nincs saját tényleges tartalma, de egy szoftvercsomag gyüjtemény telepítésére szolgál. Például a kde-plasma/plasma-meta csomag telepíti a KDE Plasma asztali környezetet az operációs rendszerünkre úgy, hogy különféle Plasma-val kapcsolatos csomagokat húz be függőségként.

Az ilyen szoftvercsomag eltávolítása az operációs rendszerünkből az emerge --deselect parancs futtatásával nem lesz túl hatékony, mivel a fő szoftvercsomag szoftverfüggőségét képező további szoftvercsomagok a rendszeren maradnak.

A Portage szoftvercsomag-kezelő rendelkezik azzal a funkcióval, hogy eltávolítsa az elárvult (semelyik másik szoftvercsomaghoz se nem tartozó) szoftverfüggőségeket is, de mivel a szoftverek elérhetősége dinamikusan függ, ezért fontos, hogy először teljes mértékben frissítse a rendszert, beleértve a USE jelölőzászlók módosítása során alkalmazott új változtatásokat is. Ezt követően az elárvult szoftverfüggőségek eltávolításához futtassa az emerge --depclean parancsot. Ezt követően szükség lehet azokra az alkalmazásokra, amelyek dinamikusan kapcsolódtak az eltávolított szoftverekhez, de már nincs rájuk szükség, bár a közelmúltban támogatás került beépítésre a Portage-ba.

Mindezt a következő két paranccsal lehet kezelni:

root #emerge --update --deep --newuse @world

root #emerge --ask --depclean

Szoftverlicencek

A Portage 2.1.7-es verziójától kezdődően lehetőség van a szoftvertelepítés elfogadására vagy elutasítására a licenc alapján. Az összes szoftvercsomag tartalmaz egy LICENSE bejegyzést az ebuild fájlokban. Az emerge --search category/package parancs futtatása megmutatja a szoftvercsomag licencét:

Important
Kizárás és felelősség korlátozásként az LICENSE változó egy ebuild-ben csupán útmutató a Gentoo fejlesztők és felhasználók számára. Nem jogi nyilatkozat vagy garancia arra, hogy minden fájl licencét tükrözni fogja, amelyet egy ebuild telepít. Nem szabad teljesen pontos jogi képviseletre támaszkodni az egy csomag által biztosított összes fájl esetében. Az adminisztrátoroknak mélyreható ellenőrzést kell végezniük minden egyes telepített fájl helyes licencelési igazodása és/vagy megfelelősége érdekében. Ha eltérést talál az ebuild-ben, akkor kérjük, hogy jelentse be a hibát, hogy javaslatot tegyen az ebuild LICENSE változójának értékének módosítására.

Alapértelmezés szerint a Portage engedélyezi azokat a licenceket, amelyeket kifejezetten jóváhagyott a Free Software Foundation, a Open Source Initiative vagy amelyek követik a Free Software Definition irányelveit.

Az engedélyezett licenceket szabályozó változó neve ACCEPT_LICENSE, amely beállítható a /etc/portage/make.conf fájlban. A következő példában az alapértelmezett érték látható:

FILE /etc/portage/make.confAz alapértelmezett ACCEPT_LICENSE beállítása

ACCEPT_LICENSE="-* @FREE"

Ezzel a beállítással az ingyenes szoftver- vagy dokumentációs licenccel rendelkező szoftvercsomagok lesznek telepíthetők. A nem ingyenes szoftverek nem lesznek telepíthetők.

Az ACCEPT_LICENSE változót Ön globálisan beállíthatja a /etc/portage/make.conf fájlban, vagy szoftvercsomagonként is megadhatja a /etc/portage/package.license fájlban.

Például, ha engedélyezni szeretné a www-client/google-chrome szoftvercsomaghoz tartozó google-chrome licencet, akkor adja hozzá a következőt a /etc/portage/package.license fájlhoz:

FILE /etc/portage/package.licenseA google-chrome licenc elfogadása a google-chrome szoftvercsomag számára

www-client/google-chrome google-chrome

Ez lehetővé teszi a www-client/google-chrome szoftvercsomag telepítését, de megakadályozza a www-plugins/chrome-binary-plugins szoftvercsomag telepítését, még akkor is, ha ugyanaz a licenc.

Vagy a gyakran szükséges sys-kernel/linux-firmware engedélyezése:

FILE /etc/portage/package.licenseA linux-firmware szoftvercsomaghoz tartozó licencek elfogadása

# Accepting the license for linux-firmware
sys-kernel/linux-firmware linux-fw-redistributable

# Minden olyan licenc elfogadása, amely engedélyezi az szoftver továbbadását.
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Important
A licencek a /var/db/repos/gentoo/licenses/ könyvtárban találhatók, és a licenc csoportok a /var/db/repos/gentoo/profiles/license_groups fájlban vannak tárolva. Az egyes sorok első bejegyzése NAGYBETŰVEL a licenc csoport neve, és minden utána következő bejegyzés egyéni licenc.

Az ACCEPT_LICENSE változóban meghatározott licenc csoportok előtaggal rendelkeznek @ jellel. Egy lehetséges beállítás (ami a korábbi Portage alapértelmezett volt), hogy minden licencet elfogadunk, kivéve azokat a Felhasználói Licencszerződéseket (EULA-kat), amelyek olvasásához és aláírásához elfogadási megállapodás szükséges. Ehhez fogadjon el minden licencet (a * használatával), majd távolítsa el az EULA csoport licenceit az alábbiak szerint:

FILE /etc/portage/make.confMinden licenc elfogadása, kivéve az EULA licencet

ACCEPT_LICENSE="* -@EULA"

Vegye figyelembe, hogy ez a beállítás a nem ingyenes szoftvereket és dokumentációkat is elfogadja.

Amikor a Portage panaszkodik

Terminológia

Mint korábban már említettük, a Portage rendkívül erős és számos olyan funkciót támogat, amelyeket más szoftvercsomag-kezelők nem tudnak biztosítani. Ennek megértéséhez néhány aspektust magyarázunk el részletesebben, anélkül, hogy túlságosan belemennénk a részletekbe.

A Portage lehetővé teszi, hogy egyetlen szoftvercsomag különböző verziói együtt létezzenek egy rendszeren. Míg más Linux disztribúciók hajlamosak elnevezni szoftvercsomagjaikat azok verziói szerint (például gtk+2 és gtk+3), a Portage egy SLOT nevű technológiát használ. Az ebuild meghatározza az adott verzióhoz tartozó SLOT értéket. Az eltérő SLOT-okat tartalmazó ebuild-ek együtt létezhetnek ugyanazon a rendszeren. Például, a gtk+ szoftvercsomag SLOT="2" és SLOT="3" értékkel rendelkező ebuild-eket tartalmaz.

Vannak olyan szoftvercsomagok is, amelyek ugyanazt a funkcionalitást biztosítják, de eltérően vannak megvalósítva. Például a metalogd, sysklogd és syslog-ng mind rendszernaplózók. Az olyan alkalmazások, amelyek a "rendszernaplózó" elérhetőségére támaszkodnak, nem függhetnek például a metalogd-tól, mivel a többi rendszernaplózó is ugyanolyan jó választás lehet. A Portage lehetőséget biztosít virtuális szoftvercsomagok használatára: minden rendszernaplózó kizárólagos függőségként van felsorolva a naplózó szolgáltatás számára a virtuális kategória naplózó virtuális szoftvercsomagjában, így az alkalmazások a virtual/logger szoftvercsomagtól függenek. Ha telepítve van, a szoftvercsomag behúzza a szoftvercsomagban említett első naplózó szoftvercsomagot, hacsak már nem volt telepítve egy naplózó szoftvercsomag (ebben az esetben a virtuális szoftvercsomag kielégítésre került).

A Gentoo szoftvercsomag-tárolóban található szoftverek különböző ágakban helyezkedhetnek el. Alapértelmezés szerint az operációs rendszer csak azokat a szoftvercsomagokat fogadja el, amelyeket a Gentoo stabilnak ítélt meg. A legtöbb új szoftvert, amikor kötelezővé válnak, akkor a tesztelési ágba dobják át, ami azt jelenti, hogy további tesztelés szükséges, mielőtt stabilnak jelölik őket a szoftverfejlesztők. Bár az ebuildek ezekhez a szoftverekhez a Gentoo szoftvercsomag-tárolóban vannak, a Portage nem fogja frissíteni őket, amíg nem helyezik őket a stabil ágba.

Egyes szoftverek csak néhány architektúrára érhetők el. Vagy a szoftver nem működik a többi architektúrán, vagy további tesztelésre van szükség, vagy a fejlesztő, aki a szoftvert a Gentoo szoftvertárolóba beküldte, az nem tudja ellenőrizni, hogy a szoftvercsomag működik-e a különböző architektúrákon.

Minden Gentoo telepített operációs rendszer egy bizonyos profilt követ, amely többek között tartalmazza azokat a szoftvercsomagokat, amelyek szükségesek magának az operációs rendszernek a normális működéséhez.

Blokkolt szoftvercsomagok

CODE Portage figyelmeztetése a blokkolt szoftvercsomagokkal kapcsolatban

[ebuild  N     ] x11-wm/i3-4.20.1  USE="-doc -test"
[blocks B      ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)

 * Hiba: A fenti szoftvercsomaglista olyan szoftvercsomagokat tartalmaz, amelyek nem telepíthetők.
 * Egyidejűleg lett telepítve ugyan arra az operációs rendszerre.

  (x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    x11-wm/i3

  (x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
    x11-wm/i3-gaps required by @selected

Az ebuild-ek specifikus mezőket tartalmaznak, amelyek a Portage számára megadják a szoftvercsomag függőségeiket. Két lehetséges függőség létezik: a build függőségek, amelyeket a DEPEND változóban deklarálnak, és a futásidejű függőségek, amelyeket hasonlóan a RDEPEND változóban deklarálnak. Ha ezek közül az egyik függőség kifejezetten nem kompatibilis szoftvercsomagot vagy virtuális szoftvercsomagot jelöl meg, az blokkolást vált ki.

Míg a Portage legújabb verziói elég intelligensek ahhoz, hogy kisebb blokkolásokat felhasználói beavatkozás nélkül megoldjanak, időnként az ilyen blokkolásokat manuálisan kell megoldani.

Egy blokkolás kijavításához a felhasználók dönthetnek úgy, hogy nem telepítik a szoftvercsomagot, vagy először eltávolítják a konfliktust okozó szoftvercsomag. Az adott példában választhatjuk, hogy nem telepítjük az x11-wm/i3 szoftvercsomagot, vagy először eltávolítjuk az x11-wm/i3-gaps szoftvercsomagot. Általában a legjobb, ha egyszerűen megmondjuk a Portage szoftvercsomag-kezelőnek, hogy a szoftvercsomag már nem kívánatos számunkra, például a emerge --deselect x11-wm/i3-gaps parancs segítségével, hogy eltávolítsuk azt a world fájlból, ahelyett, hogy erőszakosan eltávolítanánk magát a szoftvercsomagot.

Néha blokkoló szoftvercsomagok is vannak konkrét atomokkal, például <media-video/mplayer-1.0_rc1-r2. Ebben az esetben a blokkoló szoftvercsomag újabb verzióra való frissítése megszüntetheti a blokkolást.

Az is lehetséges, hogy két, még nem telepített szoftvercsomag blokkolja egymást. Ebben a ritka esetben próbálja meg kideríteni, miért lenne szükség mindkét szoftvercsomag telepítésére. A legtöbb esetben elegendő, ha csak az egyik szoftvercsomaggal dolgozunk. Ha nem oldódik meg a probléma ezáltal, akkor kérjük, hogy nyújtson be egy hibajelentést a Gentoo hibakövető rendszerében.

Elrejtett (elmaszkolt) szoftvercsomagok

CODE Figyelmeztetés a Portage részéről az elmaszkolt szoftvercsomagokra

!!! all ebuilds that could satisfy "bootsplash" have been masked.

CODE Figyelmeztetés a Portage részéről az elmaszkolt szoftvercsomagokra

!!! possible candidates are:
  
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Amikor egy olyan szoftvercsomag telepítésére teszünk kísérletet, amely nem érhető el az operációs rendszerhez, akkor ez a elmaszkolási hiba fordul elő. A felhasználóknak meg kell próbálniuk egy másik, az operációs rendszer számára elérhető alkalmazás telepítését, vagy meg kell várniuk, amíg a szoftvercsomagot elérhetőnek jelölik. Mindig van oka annak, hogy egy szoftvercsomag el van maszkolva:

Elmaszkolás oka	Leírás
~arch keyword	Az alkalmazás nincs kellőképpen tesztelve ahhoz, hogy a stabil ágba kerüljön. Várjon néhány napot vagy hetet, és próbálja meg újra a telepítését.
-arch keyword or -* keyword	Az alkalmazás nem működik a cél architektúrán. Ha ez nem így van a valóságban, akkor kérjük, hogy jelentse a hibát.
missing keyword	Az alkalmazást még nem tesztelték a cél architektúrán. Kérje meg az architektúra portolási csapatát, hogy teszteljék a csomagot, vagy tesztelje Ön maga, és jelentse az eredményeket a Gentoo Bugzilla weboldalán. Tekintse meg a /etc/portage/package.accept_keywords és Accepting a keyword for a single package.
package.mask	A szoftvercsomag hibásnak, instabilnak vagy még rosszabbnak bizonyult, és szándékosan úgy lett megjelölve, hogy azt ne használják a felhasználók.
profile	A szoftvercsomag nem megfelelőnek bizonyult a jelenleg beállított profil számára. Az alkalmazás telepítése esetén Ön sértheti az operációs rendszert, vagy egyszerűen a szoftvercsomag nem kompatibilis az éppen használt profillal.
license	A szoftvercsomag licence nem kompatibilis az ACCEPT_LICENSE változóban lévő értékkel. Ha beállítja azt a /etc/portage/make.conf vagy a /etc/portage/package.license fájlban, akkor engedélyezze a licencet vagy a megfelelő licenccsoportot.

Szükséges USE jelölőzászló változtatások

CODE Portage figyelmeztet a USE jelölőzászló változtatásának a szükségességére

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

A hibaüzenet a következőképpen is megjelenhet, ha a --autounmask nincs beállítva:

CODE Portage hibajelzése a USE jelölőzászló változtatásának szükségességére vonatkozóan

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Ez a figyelmeztetés vagy hiba akkor fordul elő, amikor egy szoftvercsomag telepítése nemcsak egy másik szoftvercsomagtól függ, hanem azt is megköveteli, hogy az a szoftvercsomag egy adott USE jelölőzászló (vagy USE jelölőzászló készlet) beállításával legyen létrehozva. Az adott példában az app-text/feelings szoftvercsomagot USE="test" beállítással kell létrehozni, de ez a USE jelölőzászló még nincs beállítva az operációs rendszeren.

Ennek megoldásához vagy adja hozzá a kért USE jelölőzászlót a globális USE jelölőzászlóhoz a /etc/portage/make.conf fájlban, vagy állítsa be a konkrét szoftvercsomaghoz a /etc/portage/package.use fájlban.

Hiányzó szoftvercsomag függőségek

CODE Portage figyelmeztetés a hiányzó szoftverfüggőségre

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
  
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.

Az alkalmazás telepítése egy másik szoftvercsomagtól függ, amely nem elérhető az operációs rendszer számára. Ellenőrizze a Bugzilla oldalt, hogy ismert-e a probléma, és ha nem, akkor jelentse. Hacsak az operációs rendszer nincs beállítva az ágak keverésére, akkor ennek nem szabadna előfordulnia, tehát ez egy hiba.

Kétértelmű ebuild név

CODE Portage figyelmeztetés a kétértelmű ebuild nevek miatt

[ Results for search key : listen ]
[ Applications found : 2 ]
  
*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD
  
*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2
  
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

A kiválasztott alkalmazás neve több szoftvercsomaggal is megegyezik. Adja meg a kategória nevét is a probléma megoldásához. A Portage tájékoztatja a felhasználót a lehetséges egyezésekről, amelyek közül választhat.

(Fordítói megjegyzés: Az "ambiguous ebuild name" hiba azt jelenti, hogy a megadott ebuild név nem egyértelmű, és a rendszer nem tudja meghatározni, hogy melyik konkrét ebuild-re vonatkozik. Ez általában akkor fordul elő, ha több ebuild hasonló névvel rendelkezik, és a rendszer nem tud választani közöttük).

Körkörös szoftvercsomag függőségek (kőrbehivatkozások)

CODE Portage figyelmeztet a körkörös szoftverfüggőségre

!!! Error: circular dependencies: 
  
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Két (vagy több) telepítendő szoftvercsomag egymástól függ (kőrbe hivatkozik egyik a másikra), ezért nem telepíthetők. Ez nagy valószínűséggel a Gentoo szoftvercsomag-tároló egyik szoftvercsomagjának a hibája. Kérem, szinkronizáljon újra egy idő után, és próbálja meg újra a telepítést. Érdemes lehet megnézni a Bugzilla oldalon, hogy ismert-e a probléma, és ha nem, akkor jelentse azt.

Letöltés meghiúsult

CODE Portage figyelmeztet, hogy meghiúsult a letöltés

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

A Portage szoftvercsomag-kezelő nem tudta letölteni a megadott alkalmazás forráskódjait, és úgy próbálja meg folytatni a többi alkalmazás telepítését (ha alkalmazható). Ez a hiba annak köszönhető, hogy a tükörszerver nem szinkronizálódott megfelelően, vagy mert az ebuild hibás helyre mutat. Az a szerverszámítógép, ahol a forráskód fájlok fizikailag találhatóak, szintén leállhatott valamilyen oknál fogva, hiszen a mesevilágban élő liberálisok nem hinnék, de a ménkű beszokott ütni a valóságban, ilyen az élet.

Próbálja meg újra egy óra múlva, hogy kiderüljön, továbbra is fennáll-e a probléma.

Rendszerprofil védelem

CODE Portage figyelmeztetés a profilvédett csomag miatt

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

A felhasználó kérte egy olyan szoftvercsomag eltávolítását, amely az operációs rendszer alapvető szoftvercsomagjai közé tartozik. A profilban kötelezőként szerepel, ezért nem szabad eltávolítani a szóban forgó szoftvercsomagot a rendszerből.

Összefoglaló ellenőrzési hiba

CODE Összefoglaló ellenőrzési hiba

>>> checking ebuild checksums
!!! Digest verification failed:

Ez annak a jele, hogy valami baj van a Gentoo szoftvercsomag tárolójával - gyakran egy ebuild Gentoo ebuild szoftvercsomag tárolóba való elkövetésekor elkövetett hiba okozza.

(Fordítói megjegyzés: A "Digest verification failure", magyarul: "Összefoglaló ellenőrzési hiba". Ez az üzenet általában akkor jelenik meg, amikor egy fájl vagy adat integritásának ellenőrzése nem sikerül, ami azt jelenti, hogy az adat vagy a fájl sérült vagy megváltozott).

Amikor az összefoglaló ellenőrzése sikertelen, ne próbálja meg személyesen újra összefoglalni a szoftvercsomagot. A ebuild foo manifest futtatása nem fogja megoldani a problémát. Nagyon is lehetséges, hogy ront a helyzeten.

Ehelyett várjon egy-két órát, hogy a fent a szerveren szoftvercsomag-tároló megnyugodjon. Valószínű, hogy a hibát azonnal már más fejlesztők észrevették, de eltarthat egy kis ideig is, amíg a javítás eljut az rsync tükörszerverekre. Nézze meg a [Bugzilla](https://bugs.gentoo.org/) oldalon, hogy valaki már jelentette-e a problémát, vagy érdeklődjön a #gentoo (webchat) (IRC) csatornán. Ha nem történt még semmi, akkor nyugodtan jelentsen hibát az elromlott ebuild miatt.

Miután a hibát kijavították a szoftverfejlesztők, szinkronizálja újra a Gentoo ebuild szoftvertárolót, hogy megkapja a javított összefoglalót.

Important
Vigyázzon arra, hogy ne szinkronizálja a Gentoo ebuild szoftvertárolót (https://gitweb.gentoo.org/repo/gentoo.git/) naponta többször. Ahogyan azt a hivatalos Gentoo netikett irányelvek is megállapítják (és a emerge --sync futtatásakor is), azok a felhasználók, akik túl gyakran szinkronizálnak, ideiglenesen meg lesznek tiltva a további szinkronizálásoktól. Azok a visszaeső szabálysértők, akik ismételten nem tartják be ezt az irányelvet, véglegesen le lesznek tiltva. Ha nem feltétlenül szükséges, akkor gyakran az a legjobb, ha 24 órát vár a szinkronizálás előtt, hogy ne terhelje túl a Gentoo rsync tükörszervereket az újbóli szinkronizálás.

Mik azok a USE jelölőzászlók?

Az ötlet az USE jelölőzászlók mögött

A Gentoo telepítésekor a felhasználók döntenek arról, hogy milyen környezettel dolgoznak. A szerver beállítása eltér a munkaállomás beállításaitól. A játékra szánt munkaállomás különbözik a 3D renderelő munkaállomástól.

Ez nem csak a telepítendő csomagok kiválasztására igaz, hanem arra is, hogy egy adott csomagnak milyen funkciókat kell támogatnia. Ha nincs szükség OpenGL-re, akkor miért foglalkozna valaki azzal, hogy az OpenGL-t telepítse és tartsa karban, és ebből kiindulva akkor a legtöbb csomagba miért fordítsa bele az OpenLG támogatást? Ha valaki eleve nem akar KDE-t használni, akkor miért is foglalkozna az illető a KDE támogatással a csomagok lefordítása közben, tudván, hogy a binárisra lefordított kész csomagok majd anélkül is hibátlanul fognak működni?

Azért, hogy segítsen a felhasználóknak eldönteni, hogy mit telepítsenek/aktiváljanak és mit ne, a Gentoo azt akarta, hogy a felhasználó könnyen meghatározza a környezetét. Ez arra kényszeríti a felhasználót, hogy eldöntse, mit is akar valójában, és megkönnyíti a Portage csomagkezelő számára a hasznos döntések meghozatalát.

Az USE jelölőzászló definíciója

Amikor azt látja, hogy: "Írja be a USE jelölőzászlókat". Egy ilyen jelölőzászló egy kulcsszó, amely egy bizonyos koncepció támogatását és függőségi információit testesíti meg. Ha egy bizonyos USE jelölőzászló engedélyezve van, akkor a Portage csomagkezelő tudni fogja, hogy a rendszergazda támogatást kér a kiválasztott kulcsszóhoz. Természetesen ez megváltoztathatja a csomag függőségi információit. A USE jelölőzászlótól függően előfordulhat, hogy sok további függőséget kell behúzni a kért függőségi változtatások teljesítéséhez.

Nézzünk meg egy konkrét példát: A kde USE jelölőzászlót. Ha ez a jelölőzászló nincs beállítva a USE változóban (vagy ha az érték előtt mínuszjel van: -kde), akkor minden opcionális KDE támogatással rendelkező csomag a KDE támogatása nélkül lesz lefordítva. Minden csomag amely opcionális KDE-függőséggel rendelkezik az a KDE könyvtárak (mint függőségek) nélkül lesz telepítve.

Forráskódcsomagoknál, amikor a kde jelölőzászló engedélyezve van, akkor azok a csomagok KDE támogatással lesznek forráskódból futtatható bináris programkódra lefordítva, és a KDE könyvtárak függőségként lesznek telepítve.

A USE jelölőzászlók helyes definiálásával a rendszer kifejezetten a rendszergazda igényeihez lesz szabva.

USE jelölőzászlók használata

Állandó USE jelölőzászlók deklarálása

Minden USE jelölőzászló (angolul "USE flag") a USE változóban (angolul "USE variable") van deklarálva. Annak érdekében, hogy a felhasználók könnyebben kereshessék és könnyebben választhassák ki a USE jelölőzászlókat, már biztosítunk egy alapértelmezett USE összeállítást. Ez az összeállítás olyan USE jelölőzászlók gyűjteménye, amelyekről azt gondoljuk, hogy a Gentoo felhasználók gyakran használják. Ez az alapértelmezett összeállítás a kiválasztott profil részét képező make.defaults fájlokban van deklarálva.

A rendszer által figyelt profilra az /etc/portage/make.profile symlink mutat. Minden profil a többi profilon felül működik, így a végeredmény az összes profil összege. A felső profil a base profil (/var/db/repos/gentoo/profiles/base).

Az (összes) aktuálisan aktív USE jelölőzászló megtekintéséhez, használja az emerge --info parancsot:

root #emerge --info | grep ^USE

USE="a52 aac acpi alsa branding cairo cdr dbus dts ..."

Ez a változó már elég sok kulcsszót tartalmaz. Ne módosítson egyetlen make.defaults fájlt sem, azért hogy a USE változót a személyes igényekhez szabja. Ha a Gentoo kódtárolója frissül, akkor ezekben a fájlokban a módosítások visszavonásra kerülnek.

Ennek az alapértelmezett beállításnak a módosításához adjon hozzá kulcsszavakat a USE változóhoz, vagy távolítsa el azt. Ez megtehető globálisan a USE változó definiálásával az /etc/portage/make.conf fájlban. Ebben a változóban felveheti a szükséges extra USE jelölőzászlókat, vagy eltávolíthatja azokat a USE jelölőzászlókat, amelyekre már nincs szükség. Ez utóbbi úgy történik, hogy a kulcsszó elé mínuszjelet (-) helyezünk.

Például a KDE és a Qt támogatásának megszüntetéséhez, de az LDAP támogatás hozzáadásához a következő USE jelölőzászló beállítás definiálható az /etc/portage/make.conf fájlban:

FILE /etc/portage/make.confUSE frissítése a make.conf fájlban

USE="-kde -qt5 ldap"

USE jelölőzászlók deklarálása egyéni csomagok részére

Néha a felhasználók egy bizonyos USE jelölőzászlót szeretnének deklarálni egyetlen (vagy csak néhány) alkalmazáshoz, de nem rendszerszinten szeretnék azt megtenni. Ennek a műveletnek az eléréséhez a /etc/portage/package.use fájlt kell szerkeszteni. A package.use jellemzően egyetlen fájl, de lehet ugyanezen a néven könyvtár is amely fájlokat tartalmaz. Az egyezményes használattal kapcsolatban lásd az alábbi tippet, majd további információkért lásd a man 5 portage súgót. A következő példák feltételezik, hogy a package.use egyetlen darab fájl.

Például azért, hogy a VLC médialejátszó csomagnak csak Blu-ray támogatása legyen:

FILE /etc/portage/package.useBlu-ray támogatás engedélyezése a VLC médialejátszó számára

media-video/vlc bluray

Tip
Ha a package.use már könyvtár formájában létezik (egyetlen fájllal szemben), akkor a csomagok USE jelölőzászlói módosíthatók a package.use/ könyvtárban található fájlok egyszerű létrehozásával. Bármely fájlelnevezési konvenció működhet, de bölcs dolog egy koherens elnevezési sémát megvalósítani. Az egyik konvenció az, hogy egyszerűen a csomag nevét használjuk a mappában lévő fájl címeként. Például a media-video/vlc csomag bluray használata USE jelölőzászlójának beállítása a következőképpen hajtható végre:

root #echo "media-video/vlc bluray" >> /etc/portage/package.use/vlc

Hasonlóképpen lehetőség van egy adott alkalmazásnál a USE jelölőzászlók használatának kifejezetten letiltására. Például PHP-ben a bzip2 támogatás letiltásához (de minden más csomagnál meglegyen a USE jelölőzászló deklarációjával a make.conf-ban):

FILE /etc/portage/package.useA bzip2 támogatás kikapcsolása a PHP részére

dev-lang/php -bzip2

Ideiglenes USE jelölőzászlók deklarálása

Néha a felhasználóknak egy rövid pillanatra be kell állítaniuk egy USE jelölőzászlót. Az /etc/portage/make.conf kétszeri szerkesztése helyett (a USE változtatások végrehajtása és visszavonása helyett) csak deklarálja a USE változót környezeti változóként. Ne feledje, hogy ez a beállítás csak a megadott parancsra vonatkozik. Az alkalmazás újbóli emerge-legenerálása vagy frissítése (akár kifejezetten, akár a rendszerfrissítés részeként) visszavonja azokat a változtatásokat, amelyeket az (ideiglenes) USE jelölőzászló definíciója váltott ki.

A következő példa ideiglenesen eltávolítja a pulseaudio értéket a USE változóból a SeaMonkey telepítése során:

root #USE="-pulseaudio" emerge www-client/seamonkey

Elsőbbség

Természetesen van egy bizonyos elsőbbség, hogy melyik USE beállítás élvez elsőbbséget a melyik USE beállítással szemben. A USE beállítás elsőbbsége prioritás szerint rendezve (az elsőnek a legalacsonyabb a prioritása):

1. Az alapértelmezett USE beállítás deklarálva van a make.defaults fájlban amely része az Ön profiljának.
2. Felhasználó által definiált USE beállítás a /etc/portage/make.conf fájlban/mappában.
3. Felhasználó által definiált USE beállítás a /etc/portage/package.use fájlban/mappában.
4. Felhasználó által definiált USE beállítás környezeti változóként létrehozva.

A végső USE beállítás megtekintéséhez a Portage által látottak szerint futtassa az emerge --info parancsot. Ez felsorolja az összes releváns változót (beleértve a USE változót is) a jelenlegi definíciójukkal együtt, ahogyan azt a Portage ismeri.

root #emerge --info

Az egész rendszer adaptálása az új USE jelölőzászlókhoz

A USE jelölőzászlók megváltoztatása után a rendszert frissíteni kell azért, hogy tükrözze a szükséges változtatásokat. Azért, hogy ezt elvégezze, futtassa az emerge parancsot a --newuse kapcsolóval:

root #emerge --update --deep --newuse @world

Ezután futtassa a Portage depclean parancsát, hogy eltávolítsa azokat a feltételes függőségeket, amelyek a "régi" rendszeren jelentek meg, de amelyeket az új USE jelölőzászlók elavultnak.

Important
Ellenőrizze még egyszer az "elavult (obsoleted)" csomagok listáját, azért hogy megbizonyosodjon arról, hogy nem távolítja el azokat a csomagokat amelyekre szükség van. A következő példa szerint adja hozzá a --pretend (-p) kapcsolót, azért hogy a depclean csak kilistázza a csomagokat anélkül, hogy ténylegesen megkezdődne azok eltávolítása:

root #emerge --pretend --depclean

Ha a depclean befejeződött, akkor az emerge kérheti az alkalmazások újbóli legenerálását, amelyek dinamikusan kapcsolódnak az esetlegesen eltávolított csomagok által biztosított megosztott objektumokhoz. A Portage megőrzi a szükséges könyvtárakat mindaddig, amíg ezt a műveletet el nem végzik, azért hogy meg legyen akadályozva az alkalmazások megtörése. Az újra legenerálandót a preserved-rebuild készletben tárolja. Futtassa a szükséges csomagok újraépítéséhez:

root #emerge @preserved-rebuild

Ha mindez megvalósult, akkor a rendszer az új USE jelölőzászlókat használja.

Csomagspecifikus USE jelölőzászlók

Elérhető USE jelölőzászlók megjelenítése

Vegyük a seamonkey példáját: Milyen USE jelölőzászlókra figyel? Ennek kiderítéséhez használjuk az emerge-t a --pretend és --verbose opciókkal:

root #emerge --pretend --verbose www-client/seamonkey

These are the packages that would be merged, in order:
 
Calculating dependencies... done!
[ebuild  N     ] www-client/seamonkey-2.48_beta1::gentoo  USE="calendar chatzilla crypt dbus gmp-autoupdate ipc jemalloc pulseaudio roaming skia startup-notification -custom-cflags -custom-optimization -debug -gtk3 -jack -minimal (-neon) (-selinux) (-system-cairo) -system-harfbuzz -system-icu -system-jpeg -system-libevent -system-libvpx -system-sqlite {-test} -wifi" L10N="-ca -cs -de -en-GB -es-AR -es-ES -fi -fr -gl -hu -it -ja -lt -nb -nl -pl -pt-PT -ru -sk -sv -tr -uk -zh-CN -zh-TW" 216,860 KiB
 
Total: 1 package (1 new), Size of downloads: 216,860 KiB

Ehhez a munkához nem az emerge az egyetlen eszköz. Valójában van egy equery nevű eszköz is a csomaginformációkhoz, amely az app-portage/gentoolkit csomagban található.

root #emerge --ask app-portage/gentoolkit

Most futtassa a equery parancsot a uses argumentummal egy bizonyos csomag USE jelölőzászlóinak a megtekintéséhez. Például az app-portage/portage-utils esetében:

user $equery --nocolor uses =app-portage/portage-utils-0.93.3

[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-portage/portage-utils-0.93.3:
 U I
 + + nls       : Add Native Language Support (using gettext - GNU locale utilities)
 + + openmp    : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp"
 + + qmanifest : Build qmanifest applet, this adds additional dependencies for GPG, OpenSSL and BLAKE2B hashing
 + + qtegrity  : Build qtegrity applet, this adds additional dependencies for OpenSSL
 - - static    : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

REQUIRED_USE feltételek kielégítése

Néhány ebuild megköveteli vagy tiltja a USE jelölőzászlók bizonyos kombinációit a megfelelő működés érdekében. Ezt a REQUIRED_USE kifejezésben elhelyezett feltételek halmazán keresztül fejezzük ki. Ezek a feltételek biztosítják, hogy az összes szolgáltatás és függőség teljes legyen, és hogy a build sikeres lehessen, és a várt módon fog működni. Ha ezek közül bármelyik nem teljesül, az emerge figyelmezteti Önt, és felkéri a probléma megoldására.

Példa	Leírás
REQUIRED_USE="foo? ( bar )"	Ha a foo be van állítva, akkor a bar-t is be kell állítani.
REQUIRED_USE="foo? ( !bar )"	Ha foo be van állítva, akkor a bar nem szabad, hogy be legyen állítva.
REQUIRED_USE="foo? ( || ( bar baz ) )"	Ha foo be van állítva, akkor a bar vagy baz be kell, hogy legyen állítva.
REQUIRED_USE="^^ ( foo bar baz )"	A foo, bar, baz közül pontosan egy darab be kell, hogy legyen állítva.
REQUIRED_USE="|| ( foo bar baz )"	A foo, bar, baz közül legalább egy darab be kell, hogy legyen állítva.
REQUIRED_USE="?? ( foo bar baz )"	A foo, bar, baz közül legfeljebb egyetlen darabot be lehet állítani.

Portage jellemzői

A Portage szoftvercsomag-kezelő számos további funkcióval rendelkezik, amelyek még jobbá teszik a Gentoo élményt. Sok ezek közül a funkciók közül bizonyos szoftveres eszközökön alapulnak, amelyek javítják a teljesítményt, a megbízhatóságot, a biztonságot, ...

A Portage bizonyos funkcióinak engedélyezéséhez vagy letiltásához szerkessze az /etc/portage/make.conf fájlt, és frissítse vagy állítsa be a FEATURES változót, amely az egyes funkciók kulcsszavait tartalmazza, szóközzel elválasztva. Számos esetben szükséges lesz az adott funkcióhoz szükséges további eszköz telepítése is.

Nem minden Portage által támogatott funkció szerepel itt. A teljes áttekintésért kérjük, olvassa el a make.conf man súgóját.

user $man make.conf

Ha szeretné megtudni, hogy milyen FEATURES vannak alapértelmezés szerint beállítva, akkor futtassa a emerge --info parancsot, és keresse meg a FEATURES változót, vagy használja a grep parancsot:

user $emerge --info | grep ^FEATURES=

Elosztott kódfordítás

A distcc használata

A distcc egy program, amely a kódfordítási feladatokat több, nem feltétlenül azonos számítógépre osztja szét egy hálózaton. A distcc kliensprogram minden szükséges információt elküld a rendelkezésre álló distcc szerverek programnak (amelyeken a distccd szoftver fut), így azok le tudják fordítani a forráskód egyes részeit a kliens számára. Az eredmény a gyorsabb kódfordítási idő.

További információk a distcc szoftverről (és arról, hogy miként működik a Gentoo-val) megtalálhatók a Distcc cikkben.

A distcc telepítése

A distcc egy grafikus monitorral érkezik, amely figyeli azokat a feladatokat, amelyeket a számítógép a fordításra küld. Ez az eszköz automatikusan települ, ha a USE="gtk" beállítás van megadva.

root #emerge --ask sys-devel/distcc

A Portage distcc támogatásának aktiválása

Adja hozzá a distcc értéket a FEATURES változóhoz az /etc/portage/make.conf fájlban. Ezután szerkessze a MAKEOPTS változót, és növelje a rendszer által engedélyezett párhuzamos build feladatok számát. Egy ismert irányelv az, hogy a -jN értéket állítsa be, ahol N a distccd programon futtató processzorok száma (beleértve az aktuális gazdagépet) plusz egy, de ez csak egy irányelv.

Most futtassa a distcc-config parancsot, és adja meg a rendelkezésre álló distcc szerverek listáját. A következő egyszerű példában feltételezzük, hogy a rendelkezésre álló DistCC szerverek a következők: 192.168.1.102 (az aktuális gazdagép), 192.168.1.103 és 192.168.1.104 (kettő "távoli" gazdagép):

root #distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Ne felejtse el futtatni a distccd szolgáltatást is:

root #rc-update add distccd default

root #/etc/init.d/distccd start

Kódfordítási objektumok gyorsítótárazása

A ccache szoftverről

A ccache egy gyors kódfordításnál használatos gyorsítótár. Amikor egy alkalmazást épp fordításban van, akkor tárolja a köztes eredményeket, így amikor ugyanaz a programverzió forráskódja újra van binárisra fordítva, akkor a fordítási idő jelentősen csökken. Az első alkalommal, amikor a ccache fut, sokkal lassabb lesz, mint egy normál fordítás. Azonban a későbbi újrafordítások gyorsabbak lesznek. A ccache csak akkor hasznos, ha ugyanazt az alkalmazás verziót sokszor fordítják újra, így többnyire csak a szoftverfejlesztők számára hasznos.

A ccache programról további információkat találhat a honlapon.

Warning
A ccache programról ismert, hogy számos fordítási hibát okoz. Néha a ccache elavult kódobjektumokat vagy sérült fájlokat tart meg, ami olyan szoftvercsomagokhoz vezethet, amelyeket nem lehet telepíteni. Ha ez előfordul (például olyan hibák jelennek meg, mint "File not recognized: File truncated" a build naplókban), akkor próbálja meg újrafordítani az alkalmazást a ccache letiltásával (FEATURES="-ccache" az /etc/portage/make.conf fájlban vagy az alábbi parancssorból) mielőtt hibajelentést küldene be a fejlesztőknek:

root #FEATURES="-ccache" emerge --oneshot <category/package>

A ccache telepítése

A ccache telepítéséhez futtassa a következő parancsot:

root #emerge --ask dev-util/ccache

Portage ccache támogatás aktiválása

Nyissa meg az /etc/portage/make.conf fájlt, és adja hozzá a ccache értéket a FEATURES változóhoz. Ha a FEATURES nem létezik, akkor hozza azt létre. Ezután adjon hozzá egy új változót CCACHE_SIZE néven, és állítsa be 2G értékre:

FILE /etc/portage/make.confPortage ccache támogatásának a bekapcsolása

FEATURES="ccache"
CCACHE_SIZE="2G"

A ccache működésének ellenőrzéséhez kérje meg a ccache programot, hogy biztosítsa a statisztikáit. Mivel a Portage más ccache home könyvtárat használ, ezért szükséges ideiglenesen beállítani a CCACHE_DIR változót:

root #CCACHE_DIR="/var/tmp/ccache" ccache -s

A /var/tmp/ccache/ hely a Portage alapértelmezett ccache home könyvtára. Ezt meg lehet változtatni a CCACHE_DIR változó beállításával az /etc/portage/make.conf fájlban.

Amikor a ccache program önállóan fut, az alapértelmezett hely a ${HOME}/.ccache/ lenne, ezért a CCACHE_DIR változót be kell állítani, amikor a (Portage) ccache statisztikákat kérjük.

A ccache használata a Portage szoftvercsomag-kezelőn kívül

A Portage szoftvercsomag-kezelőn kívüli ccache fordításokhoz adja hozzá a /usr/lib/ccache/bin/ könyvtárat a PATH változó elejére (a /usr/bin előtt). Ezt úgy érheti el, hogy szerkeszti a ~/.bash_profile fájlt a felhasználó otthoni könyvtárában. A ~/.bash_profile használata egy módja a PATH változók meghatározásának.

FILE ~/.bash_profileA ccache helyének beállítása bármely más PATH változó előtt

PATH="/usr/lib/ccache/bin:${PATH}"

Bináris kódra előre lefordított szoftvercsomag támogatás

Előre elkészített szoftvercsomagok létrehozása

A Portage támogatja az előre forráskódból bináris kódra lefordított, azonnal futtatható szoftvercsomagok telepítését. Nem kell nekünk a kód lefordításával foglalkoznunk.

Előre elkészített szoftvercsomag létrehozásához használja a quickpkg parancsot, amennyiben a szoftvercsomag már telepítve van a rendszeren, vagy használja az emerge parancsot a --buildpkg vagy --buildpkgonly opciókkal.

Annak érdekében, hogy a Portage előre elkészített szoftvercsomagokat hozzon létre minden egyes telepített szoftvercsomagból, adja hozzá a buildpkg-t a FEATURES változóhoz.

További támogatás előre elkészített szoftvercsomagkészletek létrehozásához a catalyst segítségével érhető el. A catalyst-ról további információkat a Catalyst FAQ oldalon találhat.

Előre elkészített szoftvercsomagok telepítése

Bár a Gentoo nem biztosít ilyet, lehetséges központi szoftvertárolót létrehozni, ahol az előre elkészített szoftvercsomagok tárolódnak. Ennek a szoftvercsomag-tárolónak a használatához szükséges, hogy a Portage tudjon róla, és a PORTAGE_BINHOST változó erre kell, hogy mutasson. Például, ha az előre elkészített szoftvercsomag-tároló a következő helyen található: ftp://buildhost/gentoo:

FILE /etc/portage/make.confPORTAGE_BINHOST értékének a megadása

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Előre elkészített szoftvercsomag telepítéséhez adja hozzá a --getbinpkg opciót az emerge parancshoz a --usepkg opcióval együtt. Az előbbi arra utasítja az emerge programot, hogy töltse le az előre elkészített szoftvercsomagot az előzőleg meghatározott szerverről, míg az utóbbi arra kéri az emerge programot, hogy próbálja meg először az előre elkészített szoftvercsomagot telepíteni, mielőtt letöltené a forráskódokat és lefordítaná azokat.

Például, a gnumeric előre elkészített szoftvercsomagokkal történő telepítéséhez:

root #emerge --usepkg --getbinpkg gnumeric

További információkat az emerge előre elkészített szoftvercsomag opcióiról az emerge man súgójában találhat:

user $man emerge

Előre elkészített csomagok terjesztése mások számára

Ha előre elkészített szoftvercsomagokat kíván terjeszteni mások számára, győződjön meg róla, hogy ezt szabadon meg teheti-e. Ellenőrizze az upstream szoftvercsomag terjesztési feltételeit. Például egy GNU GPL alatt kiadott szoftvercsomag esetén a forráskódokat a bináris állományokkal együtt elérhetővé kell tenni.

Az ebuild-ek megadhatják a bindist korlátozást a RESTRICT változójukban, ha a lefordított binárisok nem terjeszthetők. Néha ez a korlátozás egy vagy több USE jelölőzászlóra vonatkozik.

Alapértelmezés szerint a Portage nem maszkolja el a szoftvercsomagokat korlátozások miatt. Ez globálisan megváltoztatható az ACCEPT_RESTRICT változó beállításával az /etc/portage/make.conf fájlban. Például, a bindist korlátozással rendelkező szoftvercsomagok maszkolásához adja hozzá az alábbi sort a make.conf fájlhoz:

FILE /etc/portage/make.confCsak a binárisan terjeszthető szoftvercsomagok elfogadása

ACCEPT_RESTRICT="* -bindist"

Az ACCEPT_RESTRICT változót felül lehet írni azzal, hogy az --accept-restrict opciót átadjuk az emerge parancsnak. Például a --accept-restrict=-bindist opció ideiglenesen elmaszkolja a bindist korlátozással rendelkező szoftvercsomagokat.

Érdemes beállítani az ACCEPT_LICENSE változót is a szoftvercsomagok terjesztésekor. Erről további információkat a Licenses section találhat.

Important
Minden egyes felhasználó felelőssége, hogy betartsa a szoftvercsomagok licencfeltételeit és az egyes felhasználók országának törvényeit. Az ebuild-ek által meghatározott metaadat változók (RESTRICT vagy LICENSE) iránymutatást nyújthatnak, ha a binárisok terjesztése nem engedélyezett, de a Portage kimenete vagy a Gentoo fejlesztők által megválaszolt kérdések nem jogi nyilatkozatok, és nem szabad jogi nyilatkozatként kezelni őket. Legyen óvatos, hogy betartsa a fizikai helyének a törvényeit.

Fájlok letöltése

Distfájlok ellenőrzése

A jelenleg telepített szoftvercsomagok összes eltávolított/sérült distfile-jának újbóli ellenőrzéséhez és (esetlegesen) újbóli letöltéséhez futtassa a következő parancsot:

root #emerge --ask --fetchonly --emptytree @world

Important
Ennek az oldalnak a tartalma nem vonatkozik azokra a felhasználókra, akik a Megfelelő profil kiválasztása részben a systemd profilt választották.

Futási szintek

Operációs rendszer bootolása

Amikor az operációs rendszer elindul, sok szöveg jelenik meg gyors egymásutánban. Ha Ön figyelmesen megfigyeli, akkor észreveheti, hogy ez a szöveg (általában) minden rendszerindításkor ugyanaz. Az összes ezen művelet sorozata az úgynevezett boot folyamat, amely (nagyjából) statikusan van meghatározva.

Először a boot loader (rendszerbetöltő) betölti a boot loader beállításban meghatározott kernel képfájlt a memóriába. Ezután a boot loader utasítja a processzort, hogy hajtsa végre a kernelt. Amikor a kernel betöltődik a memóriába és elindul, akkor inicializálja az összes kernel-specifikus struktúrát és feladatot, majd elindítja az init folyamatot.

Az init folyamat biztosítja, hogy az összes fájlrendszer (amely a /etc/fstab fájlban van meghatározva) fel legyen csatolva és készen álljon a használatra. Ezután végrehajt néhány, a /etc/init.d/ könyvtárban található szkriptet, amelyek elindítják azokat a szolgáltatásokat, amelyek szükségesek a rendszer sikeres bootolásához.

Végül, miután az összes szkript lefutott, az init aktiválja a virtuális konzolokat, amelyek elérhetők például a Ctrl+Alt+F1, Ctrl+Alt+F2 stb. billentyűkombinációval, és mindegyikhez hozzárendel egy speciális folyamatot, amelyet agetty-nek hívnak. Ez a folyamat biztosítja, hogy a felhasználók be tudjanak jelentkezni a login segítségével.

Init szkriptek

A /etc/init.d/ könyvtárban található szkriptek nem futnak le véletlenszerűen. Az init nem hajtja végre az összes szkriptet a /etc/init.d/ könyvtárban, csak azokat, amelyek futtatására a /etc/runlevels/ könyvtárban található beállítások alapján utasítást kap.

Először az init azokat a szkripteket futtatja a /etc/init.d/ könyvtárból, amelyek szimbolikus hivatkozásokat tartalmaznak a /etc/runlevels/boot/ könyvtárban. Általában betűrendben indítja el a szkripteket, de néhány szkriptben függőségi információk találhatók, amelyek megmondják a rendszernek, hogy egy másik szkriptet előbb kell futtatni, mielőtt elindíthatók lennének.

Miután az összes, a /etc/runlevels/boot/ könyvtárban hivatkozott szkript lefutott, az init a /etc/runlevels/default/ könyvtárba hivatkozott szkripteket fogja végrehajtani. Ismételten az ábécé sorrendjét használja annak meghatározásához, hogy melyik szkriptet futtassa először, kivéve, ha egy szkript függőségi információkat tartalmaz, ebben az esetben a sorrendet módosítják a helyes indítási sorrend érdekében. Ezért használnak a Gentoo Linux telepítése során végrehajtott parancsok a default futási szintet (például rc-update add sshd default).

Hogyan működik az init

Természetesen az init önmagában nem dönt el mindent. Szüksége van egy beállításfájlra, amely meghatározza, milyen műveleteket kell végrehajtania. Az /etc/inittab fájlt az init használja annak meghatározására, hogy milyen lépéseket kell megtennie.

Amint azt fentebb leírtuk, az init első művelete az összes fájlrendszer felcsatolása. Ezt a következő sor határozza meg az /etc/inittab fájlban:

FILE /etc/inittabInicializálási parancs

si::sysinit:/sbin/openrc sysinit

Ez a sor azt mondja az init számára, hogy futtatnia kell a /sbin/openrc sysinit parancsot a rendszer inicializálásához. A /sbin/openrc script gondoskodik az inicializálásról, tehát mondhatjuk, hogy az init nem sokat csinál - az inicializálás feladatát egy másik folyamatra bízza.

Másodszor, az init végrehajtotta az összes szkriptet, amely szimbolikus hivatkozásokat tartalmazott a /etc/runlevels/boot/ könyvtárban. Ez a következő sorban van meghatározva:

FILE /etc/inittabBoot parancs meghívása

rc::bootwait:/sbin/openrc boot

Ismételten az OpenRC script végzi el a szükséges feladatokat. Vegye észre, hogy az OpenRC-nek adott opció (boot) ugyanaz, mint a használt /etc/runlevels/ alkönyvtár.

Most az init ellenőrzi a beállítófájlját, hogy meghatározza, melyik futási szintet (runlevel-t) kell futtatnia. Ennek eldöntéséhez a következő sort olvassa be a /etc/inittab fájlból:

FILE /etc/inittabAlapértelmezett futási szint kiválasztása

id:3:initdefault:

Ebben az esetben (amit a Gentoo felhasználók többsége használni fog), a futási szint azonosítója 3. Ezen információ alapján az init ellenőrzi, hogy mit kell futtatnia a 3-as futási szint elindításához:

FILE /etc/inittabFutási szint definíciók

l0:0:wait:/sbin/openrc shutdown
l1:S1:wait:/sbin/openrc single
l2:2:wait:/sbin/openrc nonetwork
l3:3:wait:/sbin/openrc default
l4:4:wait:/sbin/openrc default
l5:5:wait:/sbin/openrc default
l6:6:wait:/sbin/openrc reboot

A 3-as szintet meghatározó sor ismét az openrc szkriptet használja a szolgáltatások elindítására (most a default argumentummal). Érdemes megjegyezni, hogy az openrc argumentuma megegyezik a /etc/runlevels/ alkönyvtár nevével.

Amikor az OpenRC befejeződött, az init eldönti, mely virtuális konzolokat kell aktiválnia, és milyen parancsokat kell futtatnia minden egyes konzolon:

FILE /etc/inittabTermináldefiníciók

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Elérhető futási szintek

Egy korábbi részben láttuk, hogy az init egy számozási séma alapján dönti el, melyik futási szintet kell aktiválnia. A futási szint egy olyan állapot, amelyben a rendszer működik, és tartalmaz egy sor szkriptet (futási szint szkript vagy initszkript), amelyeket végre kell hajtani a futási szintbe való belépéskor vagy annak elhagyásakor.

A Gentoo rendszerben hét futási szint van definiálva: három belső futási szint és négy felhasználó által meghatározott futási szint. A belső futási szintek a sysinit, shutdown és reboot nevet viselik, és pontosan azt teszik, amit a nevük sugall: inicializálják a rendszert, lekapcsolják a rendszert, illetve újraindítják a rendszert.

A felhasználó által meghatározott futási szintek azok, amelyekhez tartozik egy /etc/runlevels/ alkönyvtár: boot, default, nonetwork és single. A boot futási szint elindítja az összes olyan rendszerhez szükséges szolgáltatást, amelyet a többi futási szint is használ. A fennmaradó három futási szint abban különbözik, hogy milyen szolgáltatásokat indítanak el: a default a mindennapi műveletekhez használatos, a nonetwork akkor alkalmazandó, ha nincs szükség hálózati kapcsolatra, míg a single akkor használatos, amikor a rendszert javítani kell.

Dolgozás az init szkriptekkel

Az openrc folyamat által indított szkripteket init szkriptnek nevezzük. Az /etc/init.d/ könyvtárban található minden szkript a következő argumentumokkal hajtható végre: start, stop, restart, zap, status, ineed, iuse, iwant, needsme, usesme vagy wantsme.

Egy szolgáltatás (és az összes függő szolgáltatás) elindításához, leállításához vagy újraindításához a start, stop és restart argumentumokat kell használni:

root #rc-service postfix start

Note
Csak azok a szolgáltatások kerülnek leállításra vagy újraindításra, amelyek az adott szolgáltatást igénylik. A többi függő szolgáltatás (amelyek használják a szolgáltatást, de nem igénylik azt) érintetlen marad.

Egy szolgáltatás leállításához, de nem a hozzá kapcsolódó szolgáltatásokhoz, használja a --nodeps opciót a stop argumentummal együtt:

root #rc-service --nodeps postfix stop

Egy szolgáltatás állapotának lekérdezéséhez (elindítva, leállítva, stb.) használja a status argumentumot.

root #rc-service postfix status

Ha az állapotinformációk azt mutatják, hogy a szolgáltatás fut, de valójában nem, akkor az állapotinformációkat a zap argumentummal "leállított" állapotra állíthatja vissza:

root #rc-service postfix zap

A szolgáltatás függőségeinek lekérdezéséhez használhatja az iwant, iuse vagy ineed argumentumokat. Az ineed segítségével megjeleníthetők azok a szolgáltatások, amelyek valóban szükségesek a szolgáltatás helyes működéséhez. Az iwant vagy az iuse viszont azokat a szolgáltatásokat mutatja meg, amelyek használhatók a szolgáltatással, de nem elengedhetetlenek annak helyes működéséhez.

root #rc-service postfix ineed

Hasonlóképpen lehetséges megkérdezni, hogy mely szolgáltatások igénylik a szolgáltatást (needsme), vagy használhatják azt (usesme vagy wantsme):

root #rc-service postfix needsme

Futási szintek frissítése

rc-update

A Gentoo init rendszere egy függőségi fát használ annak eldöntéséhez, hogy melyik szolgáltatást kell először elindítani. Mivel ez fárasztó feladat, amelyet nem szeretnénk, hogy a felhasználók kézzel végezzenek, olyan eszközöket hoztunk létre, amelyek megkönnyítik a futási szintek és az init szkriptek kezelését.

Az rc-update segítségével lehetőség van init szkripteket hozzáadni és eltávolítani egy futási szintről. Az rc-update eszköz automatikusan kéri majd a depscan.sh szkriptet a függőségi fa újraépítésére.

Szolgáltatások hozzáadása és eltávolítása

Az előző utasításokban az init szkriptek már hozzá lettek adva a default futási szinthez. A default jelentését korábban ebben a dokumentumban már magyaráztuk. A futási szint mellett az rc-update szkript egy második argumentumot is igényel, amely meghatározza a műveletet: add, del vagy show.

A futási szint mellett az rc-update szkript egy második argumentumot is igényel, amely meghatározza a megfelelő műveletet: add, del vagy show. Például:

root #rc-update del postfix default

A rc-update -v show parancs megjeleníti az összes elérhető init szkriptet és azokat a futási szinteket, amelyekben végrehajtásra kerülnek:

root #rc-update -v show

Lehetőség van a rc-update show parancs futtatására (a -v nélkül) is, hogy csak az engedélyezett init szkripteket és azok futási szintjeit tekintsük meg.

Szolgáltatások beállítása

Miért van szükség a további beállításra?

Az init szkriptek meglehetősen összetettek lehetnek, ezért nem célszerű, hogy a felhasználók közvetlenül szerkesszék ezeket, mivel ez növelheti a hibázás lehetőségét. Ugyanakkor fontos, hogy a szolgáltatások beállíthatóak legyenek. Például előfordulhat, hogy a felhasználók további opciókkal szeretnék futtatni a szolgáltatást.

Egy másik ok arra, hogy a beállítás az init szkripten kívül legyen, az az, hogy az init szkriptek frissítése ne vezessen a felhasználó beállításainak a visszavonásához.

A conf.d könyvtár

Gentoo egy egyszerű módot biztosít az ilyen szolgáltatások beállítására: minden beállítható init szkripthez tartozik egy fájl az /etc/conf.d/ könyvtárban. Például az apache2 init szkript (neve /etc/init.d/apache2) egy beállító fájllal rendelkezik, amelynek neve /etc/conf.d/apache2, amely tartalmazhatja az Apache 2 szerver indításakor megadott opciókat:

FILE /etc/conf.d/apache2Példa opciók az apache2 init szkripthez.

APACHE2_OPTS="-D PHP5"

Az ilyen beállítófájl csak változókat tartalmaz (ahogyan az /etc/portage/make.conf is), így nagyon könnyűvé teszi a szolgáltatások beállítását. Ez lehetővé teszi, hogy több információt adjunk meg a változókról (megjegyzésekként).

Az init szkriptek írása

Egy másik hasznos forrás az OpenRC service script guide.

Szükséges-e ez?

Nem, egy init szkript írása általában nem szükséges, mivel a Gentoo minden biztosított szolgáltatáshoz használatra kész init szkripteket biztosít. Azonban néhány felhasználó telepíthetett egy szolgáltatást Portage használata nélkül, ebben az esetben valószínűleg létre kell hozniuk egy init szkriptet.

Ne használja a szolgáltatás által biztosított init szkriptet, hacsak az nincs kifejezetten Gentoo számára írva: A Gentoo init szkriptjei nem kompatibilisek más disztribúciók init szkriptjeivel, kivéve, ha az adott disztribúció az OpenRC init rendszert használja.

Elrendezés

Az init szkript alapvető felépítése az alábbiak szerint néz ki.

CODE Példa init szkript elrendezése (tradicionálisan így néz ki)

#!/sbin/openrc-run
  
depend() {
#  (Dependency information)
}
  
start() {
#  (Commands necessary to start the service)
}
  
stop() {
#  (Commands necessary to stop the service)
}

CODE Példa init szkript elrendezés (frissített formában)

#!/sbin/openrc-run
command=/usr/bin/foo
command_args="${foo_args} --bar"
pidfile=/var/run/foo.pid
name="FooBar Daemon"
 
description="FooBar is a daemon that drinks"
extra_started_commands="drink"
description_drink="Opens mouth and reflexively swallows"
 
depend() {
#  (Dependency information)
}
 
start_pre() {
#  (Commands necessary to prepare to start the service)
    # Ensure that our dirs are correct
    checkpath --directory --owner foo:foo --mode 0775 \
        /var/run/foo /var/cache/foo
}
  
stop_post() {
#  (Commands necessary to clean up after the service)
    # Clean any spills
    rm -rf /var/cache/foo/*
}
 
drink() {
    ebegin "Starting to drink"
    ${command} --drink beer
    eend $? "Failed to drink any beer :("
}

Minden init szkriptnek tartalmaznia kell a start() függvényt vagy a command változót. Minden más rész opcionális.

Függőségek

Három függőségekkel kapcsolatos beállítás van, amelyek befolyásolhatják az init szkriptek indítását vagy sorrendjét: want, use és need. Ezek mellett két sorrendet befolyásoló módszer is létezik: before és after. Ez utóbbi kettő nem tekinthető függőségnek per se - nem okozzák az init szkript meghibásodását, ha a megadott függőség nincs ütemezve indításra (vagy nem indul el).

• A use beállítás tájékoztatja az init rendszert arról, hogy a szkript használja a kiválasztott szkript által nyújtott funkciókat, de nem függ közvetlenül tőle. Példák erre a use logger és a use dns: ha ezek a szolgáltatások elérhetők, akkor használatba kerülnek, de ha a rendszer nem rendelkezik naplózóval vagy DNS-kiszolgálóval, akkor a szolgáltatások továbbra is működni fognak. Ha a szolgáltatások léteznek, akkor azok elindulnak a szkript előtt, amely használja őket.
• A want beállítás hasonló a use-hoz, egy kivétellel. A use csak azokat a szolgáltatásokat veszi figyelembe, amelyek egy futási szinthez hozzá lettek adva; a want megpróbálja elindítani bármely elérhető szolgáltatást, még akkor is, ha az nincs hozzáadva egyetlen futási szinthez sem. A want megpróbálja elindítani a rendelkezésre álló szolgáltatást, még akkor is, ha az nincs hozzárendelve egy init szinthez sem.
• A need beállítás egy erős függőséget jelöl: egy olyan szkript, amely need-ként hivatkozik egy másikra, nem indul el, amíg az utóbbi szkript sikeresen el nem indul. Emellett, ha az need-ként megjelölt szkript újraindul, akkor az azt igénylő szkriptet is újraindítják.
• A before beállítás biztosítja, hogy a szkript egy megadott szkript előtt induljon el, ha az utóbbi része az adott futási szintnek. Tehát egy xdm init szkript, amely meghatározza, hogy before alsasound, az alsasound szkript előtt indul el, de csak akkor, ha az alsasound ugyanabban a futási szintben van ütemezve indításra. Ha az alsasound nincs ütemezve az adott futási szintre, akkor a before beállításnak nincs hatása, és a xdm akkor indul el, amikor az init rendszer azt legmegfelelőbbnek tartja.
• Hasonlóképpen, az after beállítás tájékoztatja az init rendszert arról, hogy az adott szkriptet egy megadott szkript után kell elindítani, ha az utóbbi része ugyanannak a futási szintnek. Ha nem, akkor a beállításnak nincs hatása, és a szkriptet az init rendszer akkor indítja el, amikor azt legmegfelelőbbnek tartja.

Egyértelmű, hogy a need az egyetlen "valódi" függőségi beállítás, mivel ez határozza meg, hogy a szkript elindul-e vagy sem. Az összes többi csupán azt közli az init rendszerrel, hogy a szkripteket milyen sorrendben lehet (vagy kell) elindítani.

Virtuális függőségek

Gentoo számos init szkriptje olyan dolgoktól függ, amelyek önmagukban nem init szkriptek: virtuális függőségek.

A virtuális függőség olyan függőség, amelyet egy szolgáltatás biztosít, de amelyet nem kizárólag az a szolgáltatás biztosít. Egy init szkript függhet egy rendszer naplózótól, de sokféle rendszer naplózó érhető el (metalogd, syslog-ng, sysklogd, ...). Mivel a szkript nem függhet mindegyiktől (egy értelmes rendszerben nincsenek mindezek a rendszernaplózók telepítve és futva), biztosítottuk, hogy ezek a szolgáltatások virtuális függőséget biztosítsanak.

Például, vegyük figyelembe a postfix szkript függőségi információit:

FILE /etc/init.d/postfixA postfix szolgáltatás függőségi információi

depend() {
  need net
  use logger dns
  provide mta
}

Ahogy látható, a postfix szolgáltatás:

• Megköveteli a (virtuális) net függőséget (amit például a /etc/init.d/net.eth0 biztosít).
• Használja a (virtuális) logger függőséget (amit például a /etc/init.d/syslog-ng biztosít).
• Használja a (virtuális) dns függőséget (amit például a /etc/init.d/named biztosít).
• Biztosítja a (virtuális) mta függőséget (ami minden levelező kiszolgálóra közös).

Sorrend vezérlése

Amint az előző szakaszban leírtuk, lehetséges megadni az init rendszernek, hogy milyen sorrendet használjon a szkriptek indításához (vagy leállításához). Ez a sorrend a use és need függőségi beállításokon keresztül, valamint a before és after sorrendbeállításokon keresztül valósul meg. Mivel ezeket korábban már ismertettük, nézzük meg példaként a portmap szolgáltatást, mint ilyen init szkriptet.

FILE /etc/init.d/portmapA portmap szolgáltatás függőségi információi

depend() {
  need net
  before inetd
  before xinetd
}

Lehetséges a * globális karakter használata az ugyanazon futási szinten lévő összes szolgáltatás hivatkozására, bár ez nem ajánlott.

CODE A * glob használata

depend() {
  before *
}

Ha a szolgáltatásnak helyi adathordozóra kell írnia, akkor a need localmount beállítást kell használnia. Ha bármit elhelyez a /var/run/ könyvtárban, például egy PID fájlt, akkor after bootmisc után kell elindulnia.

CODE Függőségi beállítás a localmount szükségességével és a bootmisc után

depend() {
  need localmount
  after bootmisc
}

Standard funkciók

A depend() funkció mellett szükséges meghatározni a start() függvényt is. Ez a függvény tartalmazza az összes olyan parancsot, amely szükséges a szolgáltatás inicializálásához. Javasolt az ebegin és eend függvények használata annak érdekében, hogy tájékoztassuk a felhasználót a folyamat eseményeiről.

CODE Példa start() függvény

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Do something in case a restart requires more than stop, start
  fi
  
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Mind a --exec, mind a --pidfile opciót használni kell a start() és stop() függvényekben. Ha a szolgáltatás nem hoz létre PID fájlt, akkor lehetőség szerint használja a --make-pidfile opciót, bár ajánlott ezt tesztelni, hogy megbizonyosodjon róla. Ellenkező esetben ne használjon PID fájlokat. Lehetőség van a --quiet hozzáadására is a start-stop-daemon opciókhoz, de ezt csak akkor ajánlott megtenni, ha a szolgáltatás rendkívül bőbeszédű. A --quiet használata akadályozhatja a hibakeresést, ha a szolgáltatás nem indul el.

Ne feledje, hogy a fenti példa ellenőrzi a RC_CMD változó tartalmát. Az OpenRC nem támogatja a szkript-specifikus újraindítási funkciót, ehelyett a szkriptnek ellenőriznie kell a RC_CMD változó tartalmát, hogy megállapítsa, egy függvényt (pl. start() vagy stop()) egy újraindítás részeként hívtak-e meg, vagy sem.

Note
Győződjön meg arról, hogy a --exec valóban szolgáltatást hív meg, és nem csak egy shell szkriptet, amely elindítja a szolgáltatásokat, majd kilép - ez az init szkript feladata.

További példák a start() függvényre: kérem, olvassa el az elérhető init szkriptek forráskódját a /etc/init.d/ könyvtárban.

Egy másik függvény, amelyet meg lehet (de nem kell) definiálni, a stop(). Az init rendszer elég intelligens ahhoz, hogy kitöltse ezt a függvényt önállóan, ha a start-stop-daemon van használatban.

CODE Példa stop() függvény

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Ha a szolgáltatás egy másik szkriptet futtat (például Bash, Python vagy Perl), és ez a szkript később nevet változtat (például foo.py-ról foo-ra), akkor szükséges a --name opció hozzáadása a start-stop-daemon parancshoz. Ennek az opciónak meg kell adnia azt a nevet, amire a szkript át fog változni. Ebben a példában egy szolgáltatás elindítja a foo.py fájlt, amely nevet változtat foo-ra.

CODE Példa definíció egy szolgáltatásra, amely elindítja a foo szkriptet

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

A start-stop-daemon kiváló kézikönyvoldallal rendelkezik, ha további információra van szükség:

user $man start-stop-daemon

A Gentoo init szkript szintaxisa a POSIX shellre ('sh') épül, ezért a felhasználók szabadon használhatnak sh-kompatibilis konstrukciókat a szkriptekben. Más, például kifejezetten Bash-re jellemző konstrukciókat azonban kerülni kell az init szkriptekben, hogy a szkriptek működőképesek maradjanak, függetlenül attól, hogy a Gentoo milyen változtatásokat hajt végre az init rendszerében.

Egyedi opciók hozzáadása

Ha az initszkriptnek olyan opciót kell támogatnia, amelyet még nem találkoztunk, akkor az opciót hozzá kell adni az alábbi változók egyikéhez, és létre kell hozni egy olyan függvényt, amelynek ugyanaz a neve, mint az opciónak. Például, ha egy restartdelay nevű opciót kell támogatni:

extra_commands - A parancs a szolgáltatás bármely állapotában elérhető. extra_started_commands - A parancs akkor elérhető, amikor a szolgáltatás elindult. extra_stopped_commands - A parancs akkor elérhető, amikor a szolgáltatás leállt.

CODE A restartdelay metódus példa definíciója

extra_started_commands="restartdelay"
  
restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

Important
A restart() funkció nem írható felül az OpenRC-ben!

Szolgáltatás konfigurációs változók

Ahhoz, hogy a /etc/conf.d/ könyvtárban lévő beállító fájlokat támogassuk, nem szükséges semmilyen különleges intézkedést tenni: amikor az init szkript végrehajtódnak, az alábbi fájlok automatikusan be vannak olvasva (azaz a változók használhatók):

• /etc/conf.d/YOUR_INIT_SCRIPT
• /etc/conf.d/basic
• /etc/rc.conf

Ha az init szkript virtuális függőséget biztosít (például net), akkor a függőséghez társított fájl (például /etc/conf.d/net) is be lesz olvasva.

Futtatási szint viselkedésének megváltoztatása

Kik részesülhetnek előnyben

Sok laptop felhasználó ismeri a helyzetet: otthon szükséges elindítani a net.eth0-t, de útközben nem szeretnék elindítani a net.eth0-t (mivel nincs elérhető hálózat). A Gentoo segítségével a futási szint viselkedését tetszés szerint lehet megváltoztatni.

Például létrehozható egy második "default" futási szint, amelyhez más init szkriptek rendelhetők. Indításkor a felhasználó kiválaszthatja, hogy melyik "default" futási szintet szeretné használni.

A softlevel használata

Először is hozza létre a második "alapértelmezett" futtatási szint könyvtárát. Példaként hozzuk létre az "offline" futtatási szintet:

root #mkdir /etc/runlevels/offline

Adja hozzá a szükséges init szkripteket az újonnan létrehozott futtatási szinthez. Például, ha pontos másolatot szeretne az aktuális alapértelmezett futtatási szintről, de net.eth0 nélkül:

root #cd /etc/runlevels/default

root #for service in *; do rc-update add $service offline; done

root #rc-update del net.eth0 offline

root #rc-update show offline

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Bár a net.eth0 el lett távolítva az offline futási szintről, az udev megpróbálhat elindítani bármilyen általa észlelt eszközt és elindítani a megfelelő szolgáltatásokat. Ezt a funkcionalitást hotpluggingnek nevezzük. Alapértelmezés szerint a Gentoo nem engedélyezi a hotplugging-et.

Ahhoz, hogy a hotplugging engedélyezve legyen, de csak egy kiválasztott szkriptkészlethez, használja az rc_hotplug változót a /etc/rc.conf fájlban:

FILE /etc/rc.confEngedélyezze a WLAN interfész hotplugging-jét

rc_hotplug="net.wlan !net.*"

Note
További információkért az eszköz által indított szolgáltatásokról, kérjük, nézze meg a megjegyzéseket a /etc/rc.conf fájlban.

Szerkessze a bootloader beállítását, és adjon hozzá egy új bejegyzést az offline futtatási szinthez. Ebben a bejegyzésben adja meg a softlevel=offline mint boot paramétert.

A bootlevel használata

A bootlevel használata teljesen analóg a softlevel-hez. Az egyetlen különbség az, hogy egy második "boot" futtatási szint van definiálva a második "alapértelmezett" futtatási szint helyett.

Környezeti változók

Bevezetés

A környezeti változó egy elnevezett objektum, amelyet egy vagy több alkalmazás használhat. Környezeti változók használatával könnyedén megváltoztatható egy vagy több alkalmazás beállítása.

Fontos példák

Az alábbi táblázat felsorolja a Linux rendszer által használt változókat, és leírja azok használatát. Példaértékeket a táblázat után mutatunk be.

Változó	Leírás
PATH	Ez a változó egy kettősponttal elválasztott könyvtárlistát tartalmaz, amelyekben a rendszer végrehajtható fájlokat keres. Ha egy végrehajtható fájl neve kerül beírásra (például ls, rc-update vagy emerge), de ez a végrehajtható fájl nincs a listában szereplő könyvtárak egyikében sem, akkor a rendszer nem hajtja végre azt (kivéve, ha a teljes elérési út van megadva parancsként, például /bin/ls).
ROOTPATH	Ez a változó ugyanazt a funkciót látja el, mint a PATH, de ez csak azokat a könyvtárakat sorolja fel, amelyeket ellenőrizni kell, amikor a root-felhasználó ad parancsot.
LDPATH	Ez a változó egy kettősponttal elválasztott könyvtárlistát tartalmaz, amelyeket a dinamikus linker keres a könyvtárak megtalálásához.
MANPATH	Ez a változó egy kettősponttal elválasztott könyvtárlistát tartalmaz, amelyeket a man(1) parancs keres a man oldalak megtalálásához.
INFODIR	Ez a változó egy kettősponttal elválasztott könyvtárlistát tartalmaz, amelyeket a info(1) parancs keres az információs oldalak megtalálásához.
PAGER	Ez a változó tartalmazza az elérési útvonalat ahhoz a programhoz, amelyet a fájlok tartalmának listázására használnak (például less vagy more(1)).
EDITOR	Ez a változó tartalmazza az elérési útvonalat ahhoz a programhoz, amelyet fájlok szerkesztésére használnak (például nano vagy vi).
KDEDIRS	Ez a változó egy kettősponttal elválasztott könyvtárlistát tartalmaz, amely KDE-specifikus anyagokat tartalmaz.
CONFIG_PROTECT	Ez a változó egy szóközzel elválasztott könyvtárlistát tartalmaz, amelyet a Portage szoftvercsomag-kezelőnek védenie kell a szotvercsomagok frissítése során.
CONFIG_PROTECT_MASK	Ez a változó egy szóközzel elválasztott könyvtárlistát tartalmaz, amelyet nem kell védenie a Portage szoftvercsomag-kezelőnek a szoftvercsomagok frissítése során.

Az alábbiakban bemutatjuk az összes ezen változók példadefinícióját:

CODE Példabeállítások az említett változókhoz

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
# Directories that are protected during package updates.
# Note the use of the \ (backslashes) on the end of the following lines which interprets to a single space-delimited line.
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
# Directories that are _not_ protected during package updates.
CONFIG_PROTECT_MASK="/etc/gconf"

A változók globális meghatározása

Az env.d könyvtár

A változók meghatározásának központosítása érdekében a Gentoo bevezette az /etc/env.d/ könyvtárat. Ebben a könyvtárban több fájl található, például 50baselayout, gcc/config-x86_64-pc-linux-gnu stb., amelyek tartalmazzák a nevükben említett alkalmazásokhoz szükséges változókat.

Például, amikor a gcc telepítve van, egy gcc/config-x86_64-pc-linux-gnu nevű fájl jön létre az ebuild által, amely tartalmazza a következő változók definícióit:

FILE /etc/env.d/gcc/config-x86_64-pc-linux-gnuAlapértelmezett gcc engedélyezett környezeti változók a GCC 13-hoz.

GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/13"
LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/13:/usr/lib/gcc/x86_64-pc-linux-gnu/13/32"
MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man"
INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info"
STDCXX_INCDIR="g++-v13"
CTARGET="x86_64-pc-linux-gnu"
GCC_SPECS=""
MULTIOSDIRS="../lib64:../lib"

Más disztribúciók esetén a rendszergazdáknak meg kell változtatniuk vagy hozzá kell adniuk az ilyen környezeti változó definíciókat az /etc/profile fájlban vagy más helyeken. A Gentoo ezzel szemben megkönnyíti a rendszergazdák (és a Portage) számára a környezeti változók karbantartását és kezelését anélkül, hogy figyelniük kellene a számos fájlra, amelyek környezeti változókat tartalmazhatnak.

Például, amikor a gcc frissítve van, a hozzá tartozó fájl(ok) az /etc/env.d/gcc könyvtárban is frissülnek anélkül, hogy bármilyen adminisztratív beavatkozásra lenne szükség.

Még mindig vannak olyan esetek, amikor a rendszergazdát arra kérik, hogy rendszer szinten állítson be egy bizonyos környezeti változót. Példaként vegyük a http_proxy változót. Az /etc/profile könyvtár alatt található fájl szerkesztése helyett hozzon létre egy /etc/env.d/99local nevű fájlt, és írja bele a definíciót:

FILE /etc/env.d/99localGlobális környezeti változó beállítása

http_proxy="proxy.server.com:8080"

Az összes testre szabott környezeti változóhoz ugyanazt a fájlt használva a rendszergazdák gyors áttekintést kapnak az általuk meghatározott változókról.

env-update

Számos fájl az /etc/env.d könyvtárban hozzáad definíciókat a PATH változóhoz. Ez nem hiba: amikor az env-update parancs végrehajtódik, hozzáfűzi a több definíciót, mielőtt atomikusan frissítené az egyes környezeti változókat, ezáltal megkönnyítve a szotvercsomagok (vagy rendszergazdák) számára, hogy hozzáadják saját környezeti változó beállításaikat anélkül, hogy beavatkoznának a már létező értékekbe.

Az env-update script alfabetikus sorrendben fogja hozzáadni az értékeket az /etc/env.d/ fájlok alapján. A fájlneveknek két tizedesjeggyel kell kezdődniük.

CODE Az env-update által használt frissítési sorrend

09sandbox    50baselayout     51dconf
     +------------+----------------+-----------+
CONFIG_PROTECT_MASK="/etc/sandbox.d /etc/gentoo-release /etc/dconf ..."

A változók összefűzése nem mindig történik meg, csak a következő változókkal: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH, és PYTHONPATH. Az összes többi változónál az utoljára meghatározott érték (az /etc/env.d/ fájlok ábécé sorrendje alapján) kerül felhasználásra.

Lehetséges további változókat hozzáadni ehhez az összefűzött változók listájához úgy, hogy a változó nevét hozzáadja a COLON_SEPARATED vagy a SPACE_SEPARATED változókhoz (szintén egy /etc/env.d/ fájlon belül).

Amikor az env-update végrehajtásra kerül, a szkript létrehozza az összes környezeti változót és elhelyezi őket az /etc/profile.env fájlban (amit az /etc/profile használ). Ezen kívül kivonja az információt a LDPATH változóból és ezt felhasználva létrehozza az /etc/ld.so.conf fájlt. Ezután futtatja az ldconfig parancsot, hogy újra létrehozza az /etc/ld.so.cache fájlt, amelyet a dinamikus linker használ.

A env-update hatásainak észleléséhez azonnal hajtsa végre a következő parancsot a környezet frissítéséhez. Azok a felhasználók, akik maguk telepítették a Gentoo rendszert, valószínűleg emlékeznek erre a telepítési utasítások alapján:

root #env-update && source /etc/profile

Note
A fenti parancs csak az aktuális terminálban, az új konzolokban és azok gyermekeiben frissíti a változókat. Így, ha a felhasználó X11-ben dolgozik, be kell gépelnie a source /etc/profile parancsot minden újonnan megnyitott terminálban, vagy újra kell indítania az X-et, hogy az összes új terminál betöltse az új változókat. Ha egy bejelentkezés kezelőt használnak, root jogosultsággal kell rendelkezni és újra kell indítani az /etc/init.d/xdm szolgáltatást.

Important
Nem lehetséges shell változókat használni más változók meghatározásakor. Ez azt jelenti, hogy olyan dolgok, mint a FOO="$BAR" (ahol a $BAR egy másik változó) tilosak.

Helyi változók definiálása

Felhasználó specifikus

Nem feltétlenül szükséges egy környezeti változót globálisan meghatározni. Például valaki hozzá szeretné adni a PATH változóhoz a /home/my_user/bin könyvtárat és az aktuális munkakönyvtárat (ahol a felhasználó éppen tartózkodik), de nem akarja, hogy a rendszer többi felhasználója is ezeket a könyvtárakat használja a PATH változóban. Ahhoz, hogy egy környezeti változót helyileg definiáljunk, használhatjuk a ~/.bashrc fájlt (minden interaktív shell munkamenethez) vagy a ~/.bash_profile fájlt (bejelentkezési shell munkamenetekhez):

FILE ~/.bashrcA PATH kiterjesztése helyi használatra

# A colon followed by no directory is treated as the current working directory
PATH="${PATH}:/home/my_user/bin:"

Kilépés/bejelentkezés után a PATH változó frissülni fog.

Munkamenet specifikus

Néha még szigorúbb definíciókra van szükség. Például egy felhasználó szeretné használni a binárisokat egy ideiglenes könyvtárból anélkül, hogy a teljes elérési utat kellene használnia a binárisokhoz, és anélkül, hogy ideiglenesen módosítania kellene a ~/.bashrc fájlt.

Ebben az esetben csak a jelenlegi munkamenetben definiálja a PATH változót az export parancs használatával. Amíg a felhasználó nem jelentkezik ki, a PATH változó az ideiglenes beállításokat fogja használni.

root #export PATH="${PATH}:/home/my_user/tmp/usr/bin"