Bináris szoftvercsomagok útmutatója

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Binary package guide and the translation is 100% complete.
See also
Tekintse meg a gyorstalpaló a bináris szoftvercsomagokhoz című cikket a Gentoo bináris szoftvercsomag host számítógépről előre elkészített bináris szoftvercsomagok használatáról . Ennek a cikknek tartalmaznia kell mindent, ami a nyilvános Gentoo binhost bináris szoftvercsomagjainak egyszerű használatához szükséges.

Ez az útmutató részletesen ismerteti a bináris szoftvercsomagok létrehozását, terjesztését, használatát és karbantartását. Valamint néhány speciális témát is ismertet a végéhez közeledve.

A Portage teljes mértékben támogatja az előre legyártott bináris szoftvercsomagokat a forráskódalapú ebuild-ek jól ismert támogatása mellett. A Portage használható a bináris szoftvercsomagok létrehozására, azok telepítésére, vagy a rendszerünkön lévő (összeállított) szoftvercsomagok bináris szoftvercsomagokból történő frissítésére. A Portage támogatja az előre bináris programkódra (már azonnal futtatható kódra) lefordított szoftvercsomagok letöltését azokról a szerverekről amelyek az előre lefordított bináris szoftvercsomagokat tárolják.

Note
Az ebben az útmutatóban használt összes eszköz a sys-apps/portage része, kivéve ha az másképp van jelezve.

Miért használjunk bináris szoftvercsomagokat a Gentoo operációs rendszeren?

Számos oka lehet annak, hogy az egyes rendszergazdák bináris szoftvercsomagokat szeretnek telepíteni a Gentoo operációs rendszerre:

  • Időt takaríthat meg a hasonló rendszerek frissítésével. A program-forráskódból való felépítés több időt vehet igénybe, mint a binárisokból történő telepítés. Ha több hasonló rendszert tartunk karban, esetleg néhányat régebbi hardverrel, akkor könnyebb lehet, ha csak az egyik rendszernek kell mindent forrásból lefordítania, a többi rendszer pedig a kapott bináris szoftvercsomagokat felhasználhatja azonnal. Magyarul, nem kell a kódfordítással húzni az időt.
  • Végezzen biztonságos frissítéseket. A kritikus fontosságú termelési rendszerek esetében fontos, hogy a lehető legjobban használhatóak maradjanak. Ezt megteheti egy adott ponton tartózkodó (a frissítési folyamat szakaszában egy külön gép) számítógép, amely először minden frissítést saját magának hajt végre. Amint a frissítések lefutása után kiderül, hogy továbbra is valóban jó állapotban van a gép, akkor a frissítések bináris szoftvercsomagokon keresztül alkalmazhatók a fő kritikus rendszerekre is. Ennek a megközelítésnek egy változata, hogy a frissítéseket chroot-ban hajtjuk végre ugyanazon a rendszeren, és később, az ott létrehozott binárisokat használjuk a valós (élesben működő) rendszer frissítésére.
  • Tartalékként. Gyakran a bináris szoftvercsomagok jelentik az egyetlen módot a meghibásodott rendszer (azaz meghibásodott fordító) helyreállítására. Az előre lefordított binárisok akár bináris szoftvercsomag szerveren, akár lokálisan nagy segítséget jelenthetnek az eszközlánc megszakadása esetén.
  • Segíthet nagyon régi rendszerek frissítésében. A nagyon régi rendszerek frissítésének feladata bináris szoftvercsomagok használatával könnyíthető meg. Általában hasznos a bináris szoftvercsomagok telepítése a régi rendszerekre, mert ezek telepítése/frissítése nem igényel építési idejű függőséget. A bináris szoftvercsomagok az összeállítási folyamatok hibáit is elkerülik.

Bináris szoftvercsomagok formátuma

Két bináris szoftvercsomag formátum létezik a Gentoo-ban. Az XPAK és a GPKG. A v3.0.31-től kezdve a Portage támogatja az új GPKG bináris szoftvercsomag formátumot. A GPKG formátum megoldja a régi XPAK formátummal kapcsolatos problémákat, és új funkciók előnyeit kínálja. Azonban nem kompatibilis a régi XPAK formátummal.

A Portage régebbi verzióit (<=v3.0.30) használó rendszergazdáknak továbbra is a régi XPAK formátumot kell használniuk, amely a Portage alapértelmezett beállítása ezekben a régebbi a verziókban.

Az újabb GPKG formátum tervezésének a motivációja a GLEP 78: Gentoo bináris szoftvercsomag konténer formátuma leírásban található. A bug #672672 és a bug #820578 hibaüzenet is hasznos részletekkel szolgál.

Ha a Portage szoftvercsomag-kezelőt a GPKG formátum használatára szeretné utasítani, akkor módosítsa a BINPKG_FORMAT értéket az /etc/portage/make.conf fájlban. Vegye figyelembe, hogy a Portage szoftvercsomag-kezelő jelenlegi verziói alapértelmezés szerint a gpkg formátumot használják.

FILE /etc/portage/make.confGPKG bináris szoftvercsomag formátum megadása
BINPKG_FORMAT="gpkg"

Ez az útmutató többnyire mindkét formátumra vonatkozik. Ahol nem ez a helyzet, ott fel lesz az tüntetve. Maguknak a bináris szoftvercsomag formátumoknak a technikai részleteiért tekintse meg a bináris szoftvercsomag formátum megértése című részt.

Bináris szoftvercsomagok használata

Általános előfeltételek

Az egy rendszeren elkészített bináris szoftvercsomagok számára azért, hogy azok a másik rendszereken is használhatóak legyenek, meg kell felelniük néhány követelménynek:

  • Az létrehozó, a kliens architektúrának, és a CHOST-nak meg kell egyeznie.
  • A bináris szoftvercsomagok létrehozásához használt CFLAGS és CXXFLAGS változóknak minden klienssel kompatibilisnek kell lenniük.
  • A processzorspecifikus utasításkészlet-funkciókhoz (például MMX, SSE, stb.) tartozó USE jelölőzászlókat gondosan kell kiválasztani. Minden kliensnek támogatnia kell őket.
Note
A Gentoo hivatalos Binhost projektjének részeként terjesztett bináris szoftvercsomagok minimális utasításkészletet és visszafogott fordítóbeállításokat használnak annak érdekében, hogy a lehető legszélesebb körben használhatóak legyenek. Például az amd64 kulcsszóval ellátott szoftvercsomagok a -march=x86-64 -mtune=generic paraméterrel készülnek, amely minden olyan gépen működik, amelyen az x86-64 (amd64) utasításkészlet fut.
Important
A Portage szoftvercsomag-kezelő nem tudja ellenőrizni, hogy ezek a követelmények megfelelnek-e. Kétség esetén ezeknek a beállításoknak a megőrzése a rendszergazda feladata.

*FLAGS kezelése részletesen

Az app-misc/resolve-march-native segédprogram a CFLAGS-ek azon részhalmazának megkeresésére használható, amit a kiszolgáló és a kliens(ek) is támogatnak. Például a gazdagép lehet, hogy ezzel tér vissza:

user $resolve-march-native
 -march=skylake -mabm -mrtm --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=12288 

Miközben a kliens ezzel fog visszatérni:

user $resolve-march-native
 -march=ivybridge -mno-rdrnd --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=3072 

Ebben a példában a CFLAGS beállítható a -march=ivybridge -mno-rdrnd értékre, mivel a -march=ivybridge teljes részhalmaza a -march=skylake -nek. A -mabm és a -mrtm nincs beleértve, mivel ezek nincs a kliens által támogatva. Az -mno-rdrnd azonban benne van, mivel a kliens nem támogatja az -mrdrnd-t. Azért, hogy kiderítse, hogy pontosan mely -march-ok részhalmazai másoknak, nézze meg a gcc kézikönyvet, ha nincs alkalmas részhalmaz, pl. -march=x86-64.

Opcionálisan beállítható az -mtune=some-arch vagy -mtune=native is azért, hogy megmondja a gcc-nek, hogy a kódot egy adott archívára legen ráhangolva. A -march-al ellentétben az -mtune argumentum nem akadályozza meg a kód futtatását más processzorokon. Például az ivybridge és újabb verziókkal kompatibilis, de a skylake-en a legjobban futásra hangolt kód lefordításához állítsa be a CFLAGS-eket a -march=ivybridge -mtune=skylake értékre. Ha az -mtune nincs beállítva, akkor alapértelmezés szerint a -march lesz beállítva.

Ha a -march értéket egy alacsonyabb részhalmazra módosítja a bináris szoftvercsomagok kliensen való használatához, akkor teljes újrafordításra van szükség, hogy megbizonyosodjon arról, hogy minden bináris kompatibilis a kliens processzorával, így időt takaríthat meg a nem lefordított, például a gcc/clang kizárásával:

user $emerge -e @world --exclude="acct-group/* acct-user/* virtual/* app-eselect/* sys-kernel/* sys-firmware/* dev-python/* dev-java/* dev-ruby/* dev-perl/* dev-lua/* dev-php/* dev-tex/* dev-texlive/* x11-themes/* */*-bin"

Hasonlóképpen az app-portage/cpuid2cpuflags használható a processzorspecifikus utasításkészlet USE jelzőzászlók megfelelő részhalmazának megtalálására. Például a gazdagép visszatérhet a következővel:

user $cpuid2cpuflags
 CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3 

Míg a kliens visszatérhet:

user $cpuid2cpuflags
 CPU_FLAGS_X86: avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 

Ebben a példában a CPU_FLAGS_X86 beállítható a avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3 értékre az /etc/portage/make.conf fájlban, mert ezek a jelölőzászlók a kliensen és a gazdagépen is támogatva vannak.

Ezek mellett a Portage le tudja ellenőrizni, hogy a bináris szoftvercsomag ugyanazokkal a USE jelölőzászlókkal generálódik-e le, mint amilyeneket a kliensen el vannak várva. Amíg nincs használva a --usepkgonly (-K) vagy a --getbinpkgonly (-G). Ugyanis ha egy szoftvercsomag más USE jelölőzászló kombinációval készült, akkor a Portage vagy figyelmen kívül hagyja a bináris szoftvercsomagot (és forráskódalapú buildet használ), vagy meghiúsul, attól függően, hogy a meghíváskor az emerge parancsnak átadott opciók. (Tekintse meg a Bináris szoftvercsomagok telepítése leírást).

Klienseken néhány beállításmódosításra van szükség a bináris szoftvercsomagok használatához.

Bináris szoftvercsomagok telepítése

Létezik néhány opció, amit át lehet adni a emerge parancsnak. Ezekkel az opciókkal tájékoztatni lehet a Portage szoftvercsomag-kezelőt a bináris szoftvercsomagok használatáról:

Opció Leírás
--usepkg (-k) Megpróbálja használni a bináris szoftvercsomag(oka)t a helyileg elérhető packages könyvtárában. NFS vagy SSHFS csatolt bináris szoftvercsomag host számítógépek használatakor hasznos. Ha a bináris szoftvercsomagok nem találhatók, akkor megszokott (forráskódalapú) telepítés történik.
--usepkgonly (-K) Hasonló a --usepkg (-k) opcióhoz, de sikertelen, ha a bináris szoftvercsomag nem található. Ez az opció akkor hasznos, ha csak előre elkészített bináris szoftvercsomagokat használunk.
--getbinpkg (-g) Töltse le a bináris szoftvercsomag(oka)t egy távoli bináris szoftvercsomag host számítógépről. Ha a bináris szoftvercsomagok nem találhatók, akkor rendszeres (forráskódalapú) telepítés történik.
--getbinpkgonly (-G) Hasonló a --getbinpkg (-g) -hez, de meghiúsul, ha a bináris szoftvercsomag(ok) nem tölthetők le. Ez az opció akkor hasznos, ha csak előre elkészített bináris szoftvercsomagokat használunk.

A bináris szoftvercsomag telepítések automatikus használatához a megfelelő opciót hozzáadhatjuk az EMERGE_DEFAULT_OPTS változóhoz:

FILE /etc/portage/make.confAutomatically fetch binary packages and build from source if not available
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --getbinpkg"

Létezik egy Portage funkció, amely arra kényszeríti az emerge parancsot, hogy mindig próbálja meg a fájlokat a bináris szoftvercsomagokat tároló host számítógépről letölteni:

FILE /etc/portage/make.confEnabling getbinpkg in the FEATURES variable
FEATURES="getbinpkg"

Megjegyzendő, hogy ez nem egyenértékű az --getbinpkg (-g) opcióval az EMERGE_DEFAULT_OPTS változóban. Különösen az --getbinpkg=n parancssori beállítás nem írja felül ezt a funkciót.

Bináris szoftvercsomag OpenPGP digitális aláírásának az ellenőrzése

Important
Az OpenPGP aláírás és ellenőrzés csak a GPKG bináris szoftvercsomag formátumhoz érhető el.

A Portage szoftvercsomag-kezelő lehetőség szerint megpróbálja ellenőrizni a bináris szoftvercsomag aláírását, de a felhasználóknak először megbízható helyi kulcsokat kell beállítaniuk. Az app-portage/getuto használható helyi megbízhatósági horgony beállítására és a kulcsok frissítésére az /etc/portage/gnupg fájlban. A Portage automatikusan meghívja a getuto-t a --getbinpkg vagy a --getbinpkgonly paranccsal.

Ez úgy állítja be a Portage szoftvercsomag-kezelőt, hogy megbízzon a Gentoo kiadás mérnöki kulcsaiban, amint azt a sec-keys/openpgp-keys-gentoo-release szoftvercsomag is tartalmazza bináris telepítési célokra.

A beállítás módosítását rendszergazdaként lehet végrehajtani a gpg használatával a --homedir=/etc/portage/gnupg paraméterrel. Ez lehetővé teszi további aláíró kulcsok importálását (például nem szabványos telepítési forrásokhoz), és megbízhatónak nyilvánítja azokat.

Egyéni aláírókulcs hozzáadásához:

  1. Generate (or use an existing) key with signing abilities, and export the public key to a file.
  2. Run getuto if it has never run:
    root #getuto
  3. Use gpg --homedir=/etc/portage/gnupg --import public.key to import the public key in portage's keyring.
  4. Trust and sign this key using the key created by getuto. In order to do this, first get the password to unlock the key at /etc/portage/gnupg/pass, then use:
    root #gpg --homedir=/etc/portage/gnupg --edit-key YOURKEYID
    Type sign, yes, paste (or type) the password. The key is now signed. To trust it, type trust, then 4 to trust it fully. Finally, type save.
  5. Update the trustdb so that GPG considers the key valid:
    root #gpg --homedir=/etc/portage/gnupg --check-trustdb

Ha bármilyen problémába ütközik, akkor ellenőrizze, hogy létezett-e már meglévő /etc/portage/gnupg. Ha igen, akkor távolítsa el, majd ismételje meg a fenti lépéseket.

Gratulálunk, a Portage szoftvercsomag-kezelő most már működő kulcstartóval rendelkezik!

Important
Ha csak kis mértékben vagy kevésbé bízik a kulcsban, akkor az nem fog működni.

Alapértelmezés szerint a Portage csak akkor ellenőrzi a GPG aláírásokat, ha egy aláíró fájl található a szoftvercsomagban, ami lehetővé teszi a felhasználó számára a különböző forrásokból származó aláírt és aláíratlan GPKG bináris szoftvercsomagok keverését, és lehetővé teszi a régi XPAK formátumú bináris szoftvercsomagok használatát.

Ha a felhasználó kényszeríteni kívánja az aláírás ellenőrzését, akkor a binpkg-request-signature jellemzőt engedélyezni kell. Ez a jellemző feltételezi, hogy minden szoftvercsomagot alá kell írni, és elutasít minden aláíratlan szoftvercsomagot. Vegye figyelembe, hogy ez a jellemző nem támogatja a binhost-onkénti beállítást.

FILE /etc/portage/make.confEnabling Portage's binpkg-request-signature feature
# Require that all binpkgs be signed and reject them if they are not (or have an invalid sig)
FEATURES="binpkg-request-signature"

Szoftvercsomagok letöltése bináris szoftvercsomagokat tartalmazó host számítógépről

Warning
"A PORTAGE_BINHOST változó elavult, az /etc/portage/binrepos.conf beállításfájl helyén" - make.conf(5)

Bináris szoftvercsomagokat tároló gazdagép használatakor az klienseknek be kell állítaniuk a PORTAGE_BINHOST változót az /etc/portage/make.conf fájlban vagy a sync-uri változót az /etc/portage/binrepos.conf fájlban. Ennek a beállításnak a megléte nélkül a kliens nem fogja tudni, hogy hol vannak a bináris szoftvercsomagok tárolva. Ami azt eredményezi, hogy a Portage szoftvercsomag-kezelő nem fogja tudja lekérni azokat.

FILE /etc/portage/binrepos.confBináris szoftvercsomagokat tároló host számítógép sync-uri változójának a beállítása
[binhost]
sync-uri = https://example.com/binhost
priority = 10

Minden bináris szoftvercsomagokat tároló gazdagéphez egy név beállítható a zárójelben. A sync-uri változónak arra a könyvtárra kell mutatnia, amelyben a Packages szoftvercsomagok megtalálhatóak. Opcionálisan beállítható a priority (prioritás) is. Ha egy szoftvercsomag több bináris szoftvercsomag-tárolóban is létezik, akkor a szoftvercsomag a legmagasabb prioritású bináris szoftvercsomag host számítógépről lesz letöltve. Ezáltal beállítható egy preferált bináris szoftvercsomagokat tároló gazdagép.

Sok Gentoo stage tömörített fájl már rendelkezik egy előre telepített /etc/portage/binrepos.conf fájllal, amely a megfelelő bináris szoftvercsomagokra mutat, amelyek a stage felépítése során keletkeztek.

Note
A több bináris szoftvercsomag szerver támogatása némileg hiányos. Ha több szerver is kiszolgál egy bináris szoftvercsomagot ugyanahhoz a szoftvercsomag verzióhoz, akkor csak az elsőt veszi figyelembe. Ez problémás lehet, ha ezek a bináris szoftvercsomagok különböznek a USE jelölőzászló változó beállításában, és egy későbbi bináris szoftvercsomag USE jelölőzászló változó beállítása megegyezik az operációs rendszer beállításával.

Módosított bináris szoftvercsomagok újratelepítése

A --rebuilt-binaries kapcsoló megadása az emerge parancsnak azt eredményezi, hogy minden bináris fájlt újratelepít, amelyet a szoftvercsomag telepítése óta újra telepítettek. Ez abban az esetben hasznos, ha a bináris szoftvercsomagokat tároló szerveren olyan újraépítő eszközök vannak, mint a revdep-rebuild.

Egy kapcsolódó opció a --rebuilt-binaries-timestamp. Azt okozza, hogy az emerge nem veszi figyelembe a bináris szoftvercsomagokat az újratelepítésnél, ha ezeket a bináris szoftvercsomagokat a megadott időbélyeg előtt lettek létrehozva. Ez hasznos az összes szoftvercsomag újratelepítésének elkerülése érdekében, ha a bináris szoftvercsomag kiszolgálót a semmiből kellett újraépíteni, de egyébként a --rebuilt-binaries parancsot használjuk.

További kliensbeállítások

A getbinpkg jellemző mellett a Portage a binpkg-logs jellemzőt is figyeli. Azt szabályozza, hogy a sikeres bináris szoftvercsomag telepítések naplófájljait meg kell-e tartani. Kizárólag akkor releváns, ha a PORT_LOGDIR változó be van állítva, és alapértelmezés szerint engedélyezve van.

Hasonlóan a bináris szoftvercsomagok kizárásához bizonyos szoftvercsomagok vagy kategóriák esetén, az kliensek beállíthatók úgy, hogy kizárják a bináris szoftvercsomagok telepítését bizonyos szoftvercsomagok vagy kategóriák esetén.

Ennek eléréséhez használja a --usepkg-exclude opciót:

root #emerge -uDNg @world --usepkg-exclude "sys-kernel/gentoo-sources virtual/* sys-kernel/gentoo-kernel"

Az ilyen további beállítások engedélyezéséhez minden egyes emerge parancshoz adja hozzá a beállításokat a make.conf fájl EMERGE_DEFAULT_OPTS változójához:

FILE /etc/portage/make.confEnabling emerge settings on every invocation
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --usepkg-exclude 'sys-kernel/gentoo-sources virtual/*'"

Szoftvercsomagok frissítése a bináris szoftvercsomagokat tartalmazó host számítógépen

Important
Ne használja a --changed-use(-U) kapcsolót a szoftvercsomagok frissítésekor a bináris szoftvercsomagokat tároló host számítógép esetében, mert ezzel a hozzáadott vagy eltávolított USE jelölőzászlóval rendelkező szoftvercsomagok kimaradnak, ami miatt a kliens bináris szoftvercsomagból történő telepítése meghiúsul. A forrás ebuild és a bináris szoftvercsomag közötti nem egyező használat miatt történik mindez (ha az kliensnél --binpkg-respect-use=y, az alapértelmezett beállítás). Használja a --newuse(-N) kapcsolót, amely mindig létrehozza újra a szoftvercsomagokat még a hozzáadott vagy eltávolított USE jelölőzászlók esetén is, biztosítva, hogy a bináris szoftvercsomag szinkronban maradjon a forrás build-el.

Bináris szoftvercsomagok létrehozása

Három fő módszer létezik a bináris szoftvercsomagok létrehozására:

  1. Rendszeres telepítés után, a quickpkg alkalmazás használatával.
  2. Kifejezetten egy emerge művelet során a --buildpkg (-b) kapcsoló használatával.
  3. Automatikusan a buildpkg (bináris szoftvercsomagok létrehozása minden szoftvercsomaghoz) vagy buildsyspkg (bináris szoftvercsomagok csak a system set-hez) értékeinek használatával a Portage FEATURES változójában.

Mindhárom metódus létrehoz egy bináris szoftvercsomagot abban a könyvtárban, amelyre a PKGDIR változó mutat (amely alapértelmezés szerint a /var/cache/binpkgs).

A --buildpkg használata mint emerge opció

Amikor szoftvert telepítünk az emerge parancs használatával, akkor a Portage szoftvercsomag-kezelő megkérhető a bináris szoftvercsomagok létrehozására a --buildpkg (-b) kapcsolóval:

root #emerge --ask --buildpkg sys-devel/gcc

Arra is lehetőség van, hogy a Portage szoftvercsomag-kezelőt megkérjük, hogy csak létrehozza a bináris szoftvercsomagot, de úgy, hogy utána ne legyen telepítve a szoftvercsomag az élő rendszerre. Ehhez a --buildpkgonly (-B) kapcsoló használható:

root #emerge --ask --buildpkgonly sys-devel/gcc

Az utóbbi megközelítés azonban megköveteli, hogy az összes összeállítási időfüggőséget korábban telepítse.

A buildpkg megvalósítása Portage szolgáltatásként

A legáltalánosabb módja a bináris szoftvercsomagok automatikus létrehozásának amikor egy szoftvercsomagot a Portage telepít, a buildpkg lehetőség használata, amely az /etc/portage/make.conf fájlban a következőképpen állítható be:

FILE /etc/portage/make.confPortage szoftvercsomag-kezelő buildpkg lehetőségének a bekapcsolása
FEATURES="buildpkg"

Ha ez a funkció be van kapcsolva, akkor minden alkalommal, amikor a Portage szoftvert telepít, létrehoz egy bináris szoftvercsomagot is.

Egyes szoftvercsomagok létrehozásának megakadályozása

A Portage szoftvercsomag-kezelőnek meg lehet mondani, hogy ne hozzon létre bizonyos bináris szoftvercsomagokat néhány kiválasztott szoftvercsomaghoz vagy kategóriához. Ez a --buildpkg-exclude opció átadásával történik az emerge számára:

root #emerge -uDN @world --buildpkg --buildpkg-exclude "acct-*/* sys-kernel/*-sources virtual/*"

Ez olyan szoftvercsomagokhoz használható, amelyeknek alig, vagy egyáltalán nincs haszna a bináris szoftvercsomag elérhetőségéből. Példák lehetnek a Linux kernel forrás szoftvercsomagjai vagy az upstream bináris szoftvercsomagok (a -bin végződésűek, mint például a www-client/firefox-bin).

Bináris szoftvercsomag tömörítési formátumok

A bináris szoftvercsomagokon egy adott tömörítési típust lehet alkalmazni. Jelenleg a következő formátumok támogatottak: bzip2, gzip, lz4, lzip, lzop, xz, and zstd. Alapértelmezés szerint zstd van használatban. Tekintse át a man make.conf súgót, és keressen rá a BINPKG_COMPRESS kifejezésre a legfrissebb információkért.

A tömörítési formátum megadása a make.conf fájlon keresztül történik.

FILE /etc/portage/make.confBináris szoftvercsomag tömörítési formátumának a megadása
BINPKG_COMPRESS="lz4"

Vegye figyelembe, hogy a használt tömörítési típus további függőségek telepítését igényelheti, például ebben az esetben: app-arch/lz4.

Bináris szoftvercsomag aláírása OpenPGP segítségével

Important
Az OpenPGP aláírás és ellenőrzés csak a GPKG bináris szoftvercsomag formátumhoz érhető el.

Egy PGP aláírás lehetővé teszi a Portage számára, hogy ellenőrizze a bináris szoftvercsomagok létrehozóját (magyarul eredetiségvizsgálat) és integritását, valamint, hogy bizalomra alapuló műveleteket hajtson végre, amelyeknek szintén a PGP kulcsok az alapkövei. A bináris szoftvercsomag-aláíró szolgáltatás alapértelmezés szerint ki van kapcsolva. A használatához engedélyezze a binpkg-signing aláíró funkciót. Vegye figyelembe, hogy a funkció engedélyezése nincs hatással az aláírást ellenőrző funkcióra.

FILE /etc/portage/make.confPortage szoftvercsomag-kezelő gpg-keepalive lehetőségének bekapcsolása
FEATURES="binpkg-signing"

A felhasználóknak a BINPKG_GPG_SIGNING_GPG_HOME és a BINPKG_GPG_SIGNING_KEY változókat is be kell állítaniuk a Portage számára, hogy megtalálja az aláíró kulcsot.

FILE /etc/portage/make.confConfiguring Portage's signing key
BINPKG_GPG_SIGNING_GPG_HOME="/root/.gnupg"
BINPKG_GPG_SIGNING_KEY="0x1234567890ABCDEF"

A Portage szoftvercsomag-kezelő csak az elején próbálja meg feloldani a PGP privát kulcsot. Ha a felhasználó kulcsa idővel lejár, akkor fontolja meg a gpg-keepalive engedélyezését az aláírási hibák elkerülése érdekében.

FILE /etc/portage/make.confPortage szoftvercsomag-kezelő gpg-keepalive lehetőségének bekapcsolása
FEATURES="gpg-keepalive"
Tip
A gpg-agent alapértelmezés szerint 2 óra elteltével lejáratja a gyorsítótár bejegyzéseit. Ez azt jelenti, hogy alapértelmezés szerint, ha egy emerge munkamenet 2 óránál tovább tart, akkor a binpkg-ok aláírása végül meghiúsul, függetlenül a FEATURES="gpg-keepalive" paramétertől. A probléma megelőzése érdekében állítsa be a max-cache-ttl értéket valamilyen nagy értékre (pl. 34560000) a $BINPKG_GPG_SIGNING_GPG_HOME/gpg-agent.conf fájlban.

A quickpkg használata

A quickpkg alkalmazás (a Portage-ben található) egy vagy több függőségi atomot (vagy szoftvercsomag készletet) vesz fel, és bináris szoftvercsomagokat hoz létre az összes telepített szoftvercsomag számára, amely megfelel az atomnak.

Warning
Ennek a módszernek van egy figyelmeztetése: A telepített fájlokra támaszkodik, ami beállításfájlok esetén gondot okozhat. A rendszergazdák gyakran módosítják a beállításfájlokat a szoftver telepítése után. Mivel ez fontos (talán még bizalmas) adatokat is kiszivároghat a szoftvercsomagokba, a quickpkg alapértelmezés szerint nem tartalmazza a CONFIG_PROTECT metódussal védett beállításfájlokat. A beállításfájlok kötelező felvételéhez használja az --include-config vagy az --include-unmodified-config kapcsolót.

Például az összes telepített GCC verzió bináris szoftvercsomagjának a létrehozásához:

root #quickpkg sys-devel/gcc

Bináris szoftvercsomagok létrehozásához a system set számára:

root #quickpkg @system

A rendszerre telepített összes szoftvercsomag bináris szoftvercsomagjának létrehozásához használja a * glob jelölést:

root #quickpkg "*/*"

Egy bináris szoftvercsomagokat tároló számítógép beállítása

A Portage számos protokollt támogat a bináris szoftvercsomagok letöltéséhez: FTP, FTPS, HTTP, HTTPS, és SSH/SFTP. Ez lehetővé teszi a számos lehetséges bináris szoftvercsomagokat tároló számítógép megvalósítását.

Azonban a Portage nem biztosít "out-of-the-box" (már meglévő, létező, előre legyártott) módszert a bináris szoftvercsomagok terjesztésére. A kívánt beállítástól függően további szoftvereket kell telepíteni.

Webalapú bináris szoftvercsomagokat tároló host számítógép

A bináris szoftvercsomagok terjesztésének általános megközelítése egy webalapú bináris szoftvercsomagokat tároló host számítógép létrehozása.

HTTPD

Telepítse a www-servers/lighttpd szoftvercsomagot, és állítsa be úgy, hogy olvasási hozzáférést biztosítson az /etc/portage/make.conf PKGDIR helyéhez.

FILE /etc/lighttpd/lighttpd.conflighttpd beállítás példa
# add this to the end of the standard configuration
server.dir-listing = "enable"
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/var/cache/binpkgs/" )
dir-listing.activate = "enable" # optional: keep it, if you want to have a nice listing at web page at the /packages path.

Caddy

A Caddy HTTP-kiszolgáló webalapú bináris szoftvercsomag host számítógépként való beállításához hozzon létre egy Caddyfile-t, amely tartalmazza:

FILE Caddyfile
x.x.x.x:80 { # Replace x.x.x.x with your host's IPv4 address
    root * /path/to/binhost/var/cache/binpkgs
    file_server browse # Needed to server 
}

Létrehozása után futtassa a Caddy-t a következővel:

root #caddy run --config /path/to/Caddyfile

Majd az ügyfélrendszereken ennek megfelelően állítsa be a PORTAGE_BINHOST változót:

FILE /etc/portage/make.confWebalapú bináris szoftvercsomagokat tároló host számítógép használata
PORTAGE_BINHOST="http://binhost.example.com/packages"

SSH alapú bináris szoftvercsomagokat tároló host számítógép

A bináris szoftvercsomagokat tároló tükörszerver számítógépek hitelesített megközelítése érdekében a Portage beállítható úgy, hogy az SSH protokollt használja a bináris szoftvercsomagok eléréséhez.

Az SSH használatakor lehetőség van a rendszergazda (root felhasználó Linux alatt) SSH kulcsának segítségével (jelszó nélkül, mivel a telepítésnek a háttérben kell történnie) egy távoli, bináris szoftvercsomagokat tároló host számítógéphez csatlakozni.

Ennek eléréséhez először győződjön meg arról, hogy a root felhasználó SSH kulcsa engedélyezett a szerveren (a gazdagépen). Ennek meg kell történnie minden olyan gépen, amely csatlakozni fog az SSH-képes bináris gazdagéphez:

root #cat root.id_rsa.pub >> /home/binpkguser/.ssh/authorized_keys

A PORTAGE_BINHOST változó így nézhet ki:

FILE /etc/portage/make.confSetting PORTAGE_BINHOST Az SSH hozzáférés érdekében
PORTAGE_BINHOST="ssh://binpkguser@binhostserver/var/cache/binpkgs"

Ha az SSH szerver másik porton figyel (pl. 25), akkor azt a cím után kell megadni, így:

FILE /etc/portage/make.confSetting PORTAGE_BINHOST SSH hozzáférés 25-ös porton
PORTAGE_BINHOST="ssh://binpkguser@binhostserver:25/var/cache/binpkgs"
Note
Ne használja a ~/.ssh/config könyvtárban lévő SSH beállításfájlokat a portok vagy a felhasználónév beállítására. Ezt a hely figyelmen kívül van hagyva, amikor a Portage megpróbálja visszaszinkronizálni a szoftvercsomagokat a kliensre. Ehelyett állítsa be helyesen az összes beállítást a PORTAGE_BINHOST változóban.

NFS exportálva

Ha belső hálózaton használjuk a bináris szoftvercsomagokat, akkor egyszerűbb lehet a szoftvercsomagokat az NFS-on keresztül exportálni és a kliensekre csatlakoztatni.

Az /etc/exports fájl így nézhet ki:

FILE /etc/exportsSzoftvercsomagok könyvtárának az exportálása
/var/cache/binpkgs   2001:db8:81::/48(ro,no_subtree_check,root_squash) 192.168.100.0/24(ro,no_subtree_check,root_squash)

Ezután a hely a klienseken felcsatolható. Egy példa /etc/fstab bejegyzés így nézne ki:

FILE /etc/fstabBejegyzés a szoftvercsomagok könyvtárának a felcsatolása érdekében
binhost:/var/cache/binpkgs      /var/cache/binpkgs    nfs    defaults    0 0

Az NFS megosztás a helyi fájlrendszerre van felcsatlakoztatva, így nincs szükség a PORTAGE_BINHOST beállítására vagy a --getbinpkg kapcsoló használatára. Ehelyett kövesse a bináris szoftvercsomagok telepítésének szokásos eljárásait. Ne felejtse el a PKGDIR változót az NFS megosztásra ráirányítani azért, hogy a portage tudja, hogy hol találja a szoftvercsomagokat:

FILE /etc/portage/make.confSzoftvercsomagokat tároló könyvtár beállítása a portage számára
PKGDIR="/var/cache/binpkgs"
Note
{{{1}}}

Bináris szoftvercsomagok karbantartása

A bináris szoftvercsomagok exportálása és terjesztése felesleges tárhelyfoglaláshoz vezet, ha a bináris szoftvercsomaglista nincs aktívan karbantartva.

Elavult bináris szoftvercsomagok eltávolítása

A gentoolkit szoftvercsomagban található egy eclean nevű alkalmazás. Lehetővé teszi a Portage szoftvercsomag-kezelőhöz kapcsolódó változó fájlok, például letöltött forráskód fájlok és bináris szoftvercsomagok karbantartását is.

A következő parancs eltávolítja az összes bináris szoftvercsomagot, amelynek nincs megfelelő ebuild-je a telepített ebuild tárolókban:

root #eclean packages

További részletekért olvassa el az eclean cikket.

Egy másik használható eszköz a qpkg eszköz az app-portage/portage-utils szoftvercsomagból. Ez az eszköz azonban egy kicsit kevésbé beállítható.

A nem használt bináris szoftvercsomagok megtisztítása. (Abban az értelemben, hogy azt a szerver használja, amelyen a bináris szoftvercsomagok vannak):

root #qpkg -c

A Packages fájl karbantartása

Tip
A Portage szoftvercsomag-kezelő a 3.0.52 verziójától kezdve alapértelmezés szerint FEATURES=pkgdir-index-trusted beállítást nyújtja a nagyobb teljesítmény érdekében, amihez pontos Packages index szükséges. Ez letiltható, ha kényelmetlenséget okoz az index rendszeres javítása az emaint-el történő manuális változtatások után.

A packages könyvtárban létezik egy Packages nevű manifest fájl. Ez a fájl gyorsítótárként működik a szoftvercsomagok könyvtárában lévő összes bináris szoftvercsomag metaadatai számára. A fájl minden alkalommal frissül, amikor a Portage bináris szoftvercsomagot ad a könyvtárhoz. Hasonlóan az eclean is frissíti, amikor eltávolítja a bináris szoftvercsomagokat.

Ha valamilyen oknál fogva a bináris szoftvercsomagok egyszerűen törlődnek vagy a szoftvercsomagok könyvtárába másolódnak, vagy a Packages fájl megsérül vagy törlődik, akkor újra létre kell azt hozni. Ez művelet az emaint paranccsal végezhető el:

root #emaint binhost --fix

Az összes bináris szoftvercsomag gyorsítótárának törléséhez:

root #rm -r /var/cache/binpkgs/*

Haladó témakörök

Chroot-olás

Ha egy másik Portage profilhoz vagy rendszerhez hoz létre szoftvercsomagokat különböző USE jelölőzászlókkal, akkor létrehozható egy chroot.

Note
Ez a példa a /var/chroot/buildenv chroot elérési utat használja, de bármilyen elérési út használható.

A könyvtárak létrehozása

Először létre kell hozni a könyvtárakat ennek a chroot -nak:

root #mkdir --parents /var/chroot/buildenv

Szoftvercsomag építési környezet telepítése

Ezután le kell tölteni és ki kell tömöríteni a megfelelő 3. fázisú (stage 3) tarballt. Itt most az desktop profile | openrc tarball van használva:

Ez kitömöríthető a következő paranccsal:

/var/chroot/buildenv/ #tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner

Szoftvercsomag építési környezet beállítása

Important
Ha a cél számítógép multilib-et használ, az építőrendszer pedig nem, akkor a kernelt újra kell fordítani, hogy támogassa azt.
KERNEL Enabling 32bit Emulation mode
Binary Emulations --->
  [*] IA32 Emulation
General architecture-dependent options --->
  [*] Provide system calls for 32-bit time_t
CODE Equivalent .config
CONFIG_IA32_EMULATION=y
CONFIG_COMPAT_32BIT_TIME=y

A szoftvercsomag építő környezetet úgy kell beállítani, hogy megfeleljen annak a rendszernek, amelyre építi (generálja) a szoftvercsomagokat. Ennek legegyszerűbb módja az /etc/portage és /var/lib/portage/world fájl másolása. Ezt meg lehet tenni rsync paranccsal:

Note
Ezt a parancsot a build cél számítógépen kell végrehajtani, ahol a távoli host számítógépen van a chroot.
user $rsync --archive --whole-file --verbose /etc/portage/* viktor@remote_host:/var/chroot/buildenv/etc/portage
user $rsync --archive --whole-file --verbose /var/db/repos/* viktor@remote_host:/var/chroot/buildenv/var/db/repos
Note
Ez megköveteli, hogy viktor írási jogosultságokkal rendelkezzen ebben a chroot-ban. Ha ezt a módszert van használja, akkor érdemes lehet törölni a célkönyvtárat, és viktor számára tulajdonosi jogosultságot kell adni ennek a könyvtárnak, ami később megváltoztatható, azért hogy a a végén aroot tulajdona maradjon. Ezeket az jogosultságokat rekurzívan kell módosítani:
root #chown --recursive root:root /var/chroot/buildenv/etc/portage

Ezt a folyamatot meg kell ismételni a world fájlnak:

user $rsync --archive --whole-file --verbose /var/lib/portage/world viktor@remote_host:/var/chroot/buildenv/var/lib/portage/world
Note
A /var/lib/portage és a /var/lib/portage/world könyvtárnak root:portage jogosultsággal kell rendelkeznie.

A chroot beállítása

Létrehozása után a felcsatolásokat össze kell kötni, hogy a chroot működjön:

/var/chroot/buildenv #mount --types proc /proc proc
/var/chroot/buildenv #mount --rbind /dev dev
/var/chroot/buildenv #cp --dereference /etc/resolv.conf etc
Note
Ha tmpfs-t használunk a portage ideiglenes könyvtárának, akkor győződjünk meg róla, hogy az fel van csatolva a fájlrendszerbe.

Belépés a chroot környezetbe

A chroot környezetbe való belépéshez a következő parancs használható:

/var/chroot/buildenv #chroot . /bin/bash

Opcionálisan a prompt beállítható úgy, hogy tükrözze azt a tényt, hogy a chroot aktív:

/ #export PS1="(chroot) $PS1"
Kezdeti szoftvercsomag összeállítás végrehajtása
Note
Ez a lépés feltételezi, hogy a következő beállítás meg lett csinálva: a portage beállítása buildpkg használatára.

Ez a lépés nem kötelező, de újraépíti az összes szoftvercsomagot az új world -ben:

(chroot) #emerge --emptytree @world

Szoftvercsomag építése más architektúrák számára

A crossdev egy olyan eszköz, amellyel könnyedén hozhat létre keresztfordítási eszközláncokat. Ez hasznos bináris szoftvercsomagok létrehozásához olyan rendszerre történő telepítéshez, amelynek architektúrája eltér a szoftvercsomagok felépítéséhez használt rendszerétől. Gyakori példa erre a bináris szoftvercsomagok összeállítása egy olyan eszközhöz, mint az arm64 Raspberry Pi egy erősebb amd64 asztali számítógépről.

A sys-devel/crossdev telepítési útmutatója a crossdev oldalon található.

Egy keresztplatformos fordító felépítése

A crossdev használatával a következő paranccsal létrehozhatunk egy eszközláncot a kívánt rendszerhez:

root #crossdev --stable -t <arch-vendor-os-libc>

A példában, a szakasz további részében a cél egy Raspberry Pi 4 lesz:

root #crossdev --stable -t aarch64-unknown-linux-gnu

Miután ez megépült, egy eszközlánc jön létre az /usr/aarch64-unknown-linux-gnu fájlban, és úgy fog kinézni, mint egy csupasz Gentoo telepítés, ahol a Portage beállításokat a szokásos módon lehet szerkeszteni.

Tip
Az aarch64-unknown-linux-gnu lecserélése az aarch64-unknown-linux-musl-re egy rendszert építene a Musl libc-vel, nem pedig a Glibc-vel.

Alapbeállítás

A -pam jelölőzászló eltávolítása a /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf fájl USE sorából általában ajánlott egy ilyen beállításnál:

FILE /usr/aarch64-unknown-linux-gnu/etc/portage/make.confA pam USE jelölőzászló kikapcsolása
CHOST=aarch64-unknown-linux-gnu
CBUILD=x86_64-pc-linux-gnu
 
ROOT=/usr/${CHOST}/
 
ACCEPT_KEYWORDS="${ARCH}"
 
USE="${ARCH}"
 
CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
 
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Ensure pkgs from another repository are not overwritten
PKGDIR=${ROOT}var/cache/binpkgs/
 
#If you want to redefine PORTAGE_TMPDIR uncomment (and/or change the directory location) the following line
PORTAGE_TMPDIR=${ROOT}var/tmp/
 
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/var/db/repos/local/"

Profilok

Listázza ki az eszközhöz elérhető profilokat a következő futtatással:

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile list

Ezután válassza ki a legmegfelelőbb profilt:

root #PORTAGE_CONFIGROOT=/usr/aarch64-unknown-linux-gnu eselect profile set <profile number>

Egyetlen szoftvercsomag összeállítása

Ha egyetlen bináris szoftvercsomagot szeretne létrehozni az eszközön, akkor használja a következőket:

root #emerge-aarch64-unknown-linux-gnu --ask foo

World file létrehozása

A world fájlban található minden szoftvercsomag felépítéséhez, a következő parancsra van szükség:

root #emerge-aarch64-unknown-linux-gnu --emptytree @world

Bináris helye

Alapértelmezés szerint az összes bináris szoftvercsomag a /usr/aarch64-unknown-linux-gnu/var/cache/binpkgs helyen lesz tárolva. Tehát ezt a helyet kell kiválasztani, amikor a beállít egy bináris szoftvercsomag host számítógépet.

Pillanatkép készítése a szoftvercsomagok könyvtáráról

Amikor nagyszámú kliensrendszerhez telepít bináris szoftvercsomagokat, akkor érdemes lehet pillanatképeket készíteni a szoftvercsomagok könyvtáráról. Az kliensrendszerek ekkor nem közvetlenül a szoftvercsomagok könyvtárát használják, hanem a pillanatkép bináris szoftvercsomagjait.

Pillanatképek a Portage szoftvercsomag-kezelőhöz tartozó /usr/lib/portage/python3.11/binhost-snapshot eszközzel hozhatók létre. (Megjegyzendő, hogy az eszköz elérési útját módosítani kell, hogy megfeleljen a Portage telepített python verziójának). négy érv kell hozzá:

  1. Egy forráskönyvtár (a szoftvercsomagok könyvtárának elérési útja).
  2. Egy célkönyvtár (amelynek nem szabad léteznie).
  3. Egy URI.
  4. Egy bináris szoftvercsomag szerverkönyvtár.

A fájlok a szoftvercsomagkönyvtárból a célkönyvtárban másolódnak. Egy Packages fájl ezután létrejön a bináris szoftvercsomag szerverszámítógép könyvtárában (negyedik argumentum) a megadott URI-val.

Az kliensrendszereknek olyan URI-t kell használniuk, amely a bináris szoftvercsomagszerver könyvtárára mutat. Onnan átirányítják őket arra az URI-ra, amelyet a binhost-snapshot kapott. Ennek az URI-nak a célkönyvtárra kell hivatkoznia.

A bináris szoftvercsomag formátum megértése

XPAK formátum

A Portage által létrehozott XPAK formátumú bináris szoftvercsomagok fájlnevük .tbz2 végződésű. Ezek a fájlok két részből állnak:

  1. Egy .tar.bz2 archívum, amely a rendszerre telepítendő fájlokat tartalmazza.
  2. Egy xpak archívum, amely tartalmazza a szoftvercsomag metaadatait, az ebuild-et és a környezetfájlt.

Tekintse meg a man xpak formátum leírását.

Az app-portage/portage-utils-ban létezik néhány eszköz, amely képes feldarabolni vagy létrehozni tbz2 és xpak fájlokat.

A következő parancs a tbz2 fájlt feldarabolja .tar.bz2 és .xpak fájlokra:

user $qtbz2 -s <package>.tbz2

A(z) .xpak fájl a qxpak segédprogrammal vizsgálható meg.

A tartalom felsorolásához:

user $qxpak -l <package>.xpak

A következő parancs kicsomagolja a USE nevű fájlt, amely tartalmazza a szoftvercsomag engedélyezett USE jelölőzászlóit:

user $qxpak -x package-manager-0.xpak USE

GPKG formátum

A Portage által létrehozott GPKG formátumú bináris szoftvercsomagok fájlnevük a következőre végződik: .gpkg.tar. Ezek a fájlok legalább négy részből állnak:

  1. Egy gpkg-1 üres fájl, amely a formátum azonosítására szolgált.
  2. Egy C/PV/metadata.tar{.compression} archívum, amely a szoftvercsomag metaadatait, az ebuild-et és a környezetfájlt tartalmazza.
  3. Egy C/PV/image.tar{.compression} archívum, amely a rendszerre telepítendő fájlokat tartalmazza.
  4. Egy Manifest fájl, amely ellenőrző összegeket tartalmaz a fájlok sérülése elleni védelem érdekében.
  5. Több opcionális, OpenPGP aláírást tartalmazó .sig fájl is használható az integritás ellenőrzésére és a megbízhatóság igazolására.

A formátumot a tar programmal és további eszközök alkalmazása nélkül is kibontható.

Az PKGDIR elrendezés

A jelenleg használt formátum 2-es verziója a következő elrendezéssel rendelkezik:

CODE Packages könyvtár elrendezése (verzió 2)
PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1-version.tbz2
 |  `- pkgN-version.tbz2
 +- app-admin/
 |  `- ...
 `- ...

A Packages fájl a fő fejlesztés (és egyben a Portage triggere is, hogy tudja, hogy a bináris szoftvercsomagkönyvtár a 2-es verziót használja) az első bináris szoftvercsomagkönyvtár-elrendezéshez (1. verzió) képest. Az 1-es verzióban az összes bináris szoftvercsomag egyetlen könyvtárban volt tárolva All/ néven, és a kategória-könyvtárak csak szimbolikus hivatkozásokat tartalmaztak az All/ könyvtárban lévő bináris szoftvercsomagokhoz.

A portage-3.0.15 és újabb verziókban a FEATURES=binpkg-multi-instance alapértelmezés szerint engedélyezve van:

CODE Packages könyvtár elrendezése (verzió 2 + FEATURES=binpkg-multi-instance)
PKGDIR
`+- Packages
 +- app-accessibility/
 |  +- pkg1/
 |    +- pkg1-version-build_id.xpak
 |    `- pkgN-version-build_id.xpak
 +- app-admin/
 |  `- ...
 `- ...

Kicsomagolás a quickunpkg eszközzel

A zoobab nevű felhasználó írt egy quickunpkg nevű eszközt a tbz2 fájlok gyors kicsomagolásához.

További olvasnivaló a témában

Külső források

quickpkg man súgó.