Bináris csomagok útmutatója

Portage - the heart of Gentoo
emerge — configuration — ebuild repository — dispatch-conf

world file — USE flags — ebuilds — profiles
upgrades — using testing packages — binary packages
tools — gentoolkit — eselect
Portage FAQ — cheat sheet — FAQ
all articles

See also
Tekintse meg a gyorstalpaló a bináris csomagokhoz című cikket a Gentoo bináris csomag gazdagépről előre elkészített bináris csomagok használatáról . Ennek a cikknek tartalmaznia kell mindent, ami a nyilvános Gentoo binhost bináris csomagjainak egyszerű használatához szükséges.

Ez az útmutató részletesen ismerteti a bináris csomagok 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 programcsomagokat a forráskódalapú ebuild-ek jól ismert támogatása mellett. A Portage használható a bináris csomagok létrehozására, azok telepítésére, vagy a rendszerünkön lévő (összeállított) csomagok bináris-csomagokbó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 csomagok letöltését azokról a szerverekről amelyek az előre lefordított bináris-csomagokat 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 csomagokat a Gentoo rendszeren?

Számos oka lehet annak, hogy az egyes rendszergazdák bináris csomagokat szeretnek telepíteni a Gentoo-ra:

• 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 csomagokat 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 csomagokon 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 programcsomagok 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 csomagszerveren, 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 programcsomagok használatával könnyíthető meg. Általában hasznos a bináris csomagok 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 csomagok az összeállítási folyamatok hibáit is elkerülik.

Bináris csomagok formátuma

Két bináris csomagformá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 csomagformá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-csomag 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 csomagkezelő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 csomagkezelő jelenlegi verziói alapértelmezés szerint a gpkg formátumot használják.

FILE /etc/portage/make.confGPKG binary csomagformátum hozzáadá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 csomagformátumoknak a technikai részleteiért tekintse meg a bináris csomagformátum megértése című részt.

Bináris programcsomagok használata

Általános előfeltételek

Az egy rendszeren elkészített bináris csomagok 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 csomagok 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 csomagok 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 csomagok 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 csomagkezelő 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 csomagok 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 csomag 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 csomag 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 csomagot (é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 csomagok telepítése leírást).

Klienseken néhány konfigurációmódosításra van szükség a bináris csomagok használatához.

Bináris csomagok 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 csomagkezelőt a bináris csomagok használatáról:

Opció	Leírás
--usepkg (-k)	Megpróbálja használni a bináris csomag(oka)t a helyileg elérhető packages könyvtárában. NFS vagy SSHFS csatolt bináris csomaggazdagépek használatakor hasznos. Ha a bináris csomagok 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 csomag nem található. Ez az opció akkor hasznos, ha csak előre elkészített bináris csomagokat használunk.
--getbinpkg (-g)	Töltse le a bináris csomag(oka)t egy távoli bináris csomag gazdagépről. Ha a bináris csomagok 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 csomag(ok) nem tölthetők le. Ez az opció akkor hasznos, ha csak előre elkészített bináris csomagokat használunk.

A bináris csomag 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"

Van egy Portage szolgáltatás, amely automatikusan megvalósítja a --getbinpkg (-g) megfelelőjét anélkül, hogy frissítenie kellene az EMERGE_DEFAULT_OPTS változót a --getbinpkg értékkel:

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

FEATURES="getbinpkg"

Bináris programcsomag 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 csomag formátumhoz érhető el.

A Portage csomagkezelő lehetőség szerint megpróbálja ellenőrizni a bináris csomag 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 konfigurálja a Portage csomagkezelőt, hogy megbízzon a Gentoo kiadás mérnöki kulcsaiban, amint azt a sec-keys/openpgp-keys-gentoo-release csomag is tartalmazza bináris telepítési célokra.

A konfiguráció 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 csomagkezelő 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 csomagban, 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 csomagok keverését, és lehetővé teszi a régi XPAK formátumú bináris csomagok 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 csomagot alá kell írni, és elutasít minden aláíratlan csomagot. Vegye figyelembe, hogy ez a jellemző nem támogatja a binhost-onkénti konfigurációt.

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"

Csomagok letöltése bináris csomagokat tartalmazó gazdagépről

Warning
"A PORTAGE_BINHOST változó elavult, az /etc/portage/binrepos.conf konfigurációs fájl helyén" - make.conf(5)

Bináris csomagokat 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 konfigurációnak a megléte nélkül a kliens nem fogja tudni, hogy hol vannak a bináris csomagok tárolva. Ami azt eredményezi, hogy a Portage csomagkezelő nem fogja tudja lekérni azokat.

FILE /etc/portage/binrepos.confA bináris csomagokat tároló gazdagép sync-uri változójának a beállítása

[binhost]
sync-uri = https://example.com/binhost
priority = 10

Minden bináris csomagokat tároló gazdagéphez egy név konfigurálható a zárójelben. A sync-uri változónak arra a könyvtárra kell mutatnia, amelyben a Packages csomagok megtalálhatóak. Opcionálisan beállítható a priority (prioritás) is. Ha egy csomag több bináris csomagtárolóban is létezik, akkor a csomag a legmagasabb prioritású bináris csomaggazdagépről lesz letöltve. Ezáltal beállítható egy preferált bináris csomagokat 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 csomagokra mutat, amelyek a stage felépítése során keletkeztek.

Note
A több bináris csomag szerver támogatása némileg hiányos. Ha több szerver is kiszolgál egy bináris csomagot ugyanahhoz a csomagverzióhoz, akkor csak az elsőt veszi figyelembe. Ez problémás lehet, ha ezek a bináris csomagok különböznek a USE jelölőzászló változó konfigurációjában, és egy későbbi bináris csomag USE jelölőzászló változó konfigurációja megegyezik a rendszer konfigurációjával.

Módosított bináris csomagok ú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 csomag telepítése óta újra telepítettek. Ez abban az esetben hasznos, ha a bináris programcsomagokat 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 csomagokat az újratelepítésnél, ha ezeket a bináris csomagokat a megadott időbélyeg előtt lettek létrehozva. Ez hasznos az összes csomag újratelepítésének elkerülése érdekében, ha a bináris csomag 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 csomagtelepítések naplófájljait meg kell-e tartani. Csak 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 csomagok kizárásához bizonyos csomagok vagy kategóriák esetén, az kliensek beállíthatók úgy, hogy kizárják a bináris csomagok telepítését bizonyos csomagok 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/*'"

Csomagok frissítése a bináris csomagokat tartalmazó gazdagépen

Important
Ne használja a --changed-use(-U) kapcsolót a csomagok frissítésekor a bináris csomagokat tároló gazdagép esetében, mert ezzel a hozzáadott vagy eltávolított USE jelölőzászlóval rendelkező csomagok kimaradnak, ami miatt a kliens bináris csomagból történő telepítése meghiúsul. A forrás ebuild és a bináris csomag 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 csomagokat még a hozzáadott vagy eltávolított USE jelölőzászlók esetén is, biztosítva, hogy a bináris csomag szinkronban maradjon a forrás build-del.

Bináris programcsomagok létrehozása

Három fő módszer létezik a bináris csomagok 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 csomagok létrehozása minden csomaghoz) vagy buildsyspkg (bináris csomagok 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 csomagot 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 csomagkezelő megkérhető a bináris csomagok 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 csomagkezelőt megkérjük, hogy csak létrehozza a bináris csomagot, de úgy, hogy utána ne legyen telepítve a programcsomag 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 csomagok automatikus létrehozásának amikor egy csomagot 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.confA Portage csomagkezelő buildpkg lehetőségének 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 csomagot is.

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

A Portage csomagkezelőnek meg lehet mondani, hogy ne hozzon létre bizonyos bináris csomagokat néhány kiválasztott csomaghoz 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 csomagokhoz használható, amelyeknek alig, vagy egyáltalán nincs haszna a bináris csomag elérhetőségéből. Példák lehetnek a Linux kernel forráscsomagjai vagy az upstream bináris csomagok (a -bin végződésűek, mint például a www-client/firefox-bin).

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

A bináris csomagokon 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.confadja meg a bináris csomagtömörítési formátumot A bináris programcsomag 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 csomag aláírása OpenPGP segítségével

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

Egy PGP aláírás lehetővé teszi a Portage számára, hogy ellenőrizze a bináris csomagok 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 csomag-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.confA Portage csomagkezelő 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 csomagkezelő 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.confA Portage csomagkezelő 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 csomagkészletet) vesz fel, és bináris csomagokat hoz létre az összes telepített csomaghoz, amely megfelel az atomnak.

Warning
Ennek a módszernek van egy figyelmeztetése: A telepített fájlokra támaszkodik, ami konfigurációs fájlok esetén gondot okozhat. A rendszergazdák gyakran módosítják a konfigurációs fájlokat a szoftver telepítése után. Mivel ez fontos (talán még bizalmas) adatokat is kiszivároghat a csomagokba, a quickpkg alapértelmezés szerint nem tartalmazza a CONFIG_PROTECT metódussal védett konfigurációs fájlokat. A konfigurációs fá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 csomagjának létrehozásához:

root #quickpkg sys-devel/gcc

Bináris csomagok létrehozásához a system set -hez:

root #quickpkg @system

A rendszerre telepített összes csomag bináris csomagjának létrehozásához használja a * glob -ot:

root #quickpkg "*/*"

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

A Portage számos protokollt támogat a bináris csomagok letöltéséhez: FTP, FTPS, HTTP, HTTPS, és SSH/SFTP. Ez lehetővé teszi a számos lehetséges bináris csomagokat 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 csomagok terjesztésére. A kívánt beállítástól függően további szoftvereket kell telepíteni.

Webalapú bináris csomagokat tároló gazdaszámítógép

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

HTTPD

Telepítse a www-servers/lighttpd csomagot, é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 configuration example

# add this to the end of the standard configuration
server.dir-listing = "enable"
server.modules += ( "mod_alias" )
alias.url = ( "/packages" => "/var/cache/binpkgs/" )

Caddy

A Caddy HTTP-kiszolgáló webalapú bináris csomag gazdaszá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 csomagokat tároló gazdaszámítógép használata

PORTAGE_BINHOST="http://binhost.example.com/packages"

SSH alapú bináris csomagokat tároló kiszolgáló-számítógép

A bináris csomagokat tároló tülörszá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 csomagok 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 csomagokat tároló gazdaszá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 konfigurációs fá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 csomagokat 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 csomagokat, akkor egyszerűbb lehet a csomagokat az NFS-on keresztül exportálni és a kliensekre csatlakoztatni.

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

FILE /etc/exportsA csomagok könyvtárának 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 csomagok mappájának a felcsatolására

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 programcsomagok 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 csomagokat:

FILE /etc/portage/make.confA csomagokat tároló könyvtár beállítása a portage számára

PKGDIR="/var/cache/binpkgs"

Note
{{{1}}}

Bináris csomagok karbantartása

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

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

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

A következő parancs eltávolítja az összes bináris csomagot, 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 csomagból. Ez az eszköz azonban egy kicsit kevésbé konfigurálható.

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

root #qpkg -c

A Packages fájl karbantartása

Tip
A Portage csomagkezelő 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 csomagok könyvtárában lévő összes bináris csomag metaadatai számára. A fájl minden alkalommal frissül, amikor a Portage bináris csomagot ad a könyvtárhoz. Hasonlóan az eclean is frissíti, amikor eltávolítja a bináris csomagokat.

Ha valamilyen oknál fogva a bináris csomagok egyszerűen törlődnek vagy a csomagok 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 csomag 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 csomagokat 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

Az csomagé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:

/var/chroot/buildenv/ #wget https://bouncer.gentoo.org/fetch/root/all/releases/amd64/autobuilds/20230528T163158Z/stage3-amd64-desktop-openrc-20230528T163158Z.tar.xz

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

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

Az csomagé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

Az csomagépítő környezetet úgy kell beállítani, hogy megfeleljen annak a rendszernek, amelyre építi (generálja) a csomagokat. 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élgépen kell végrehajtani, ahol a távoli gazdagé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 konfigurálá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 csomag összeállítás végrehajtása

Note
Ez a lépés feltételezi, hogy a következő konfiguráció 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 csomagot az új world -ben:

(chroot) #emerge --emptytree @world

Programcsomag é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 csomagok létrehozásához olyan rendszerre történő telepítéshez, amelynek architektúrája eltér a csomagok felépítéséhez használt rendszerétől. Gyakori példa erre a bináris csomagok ö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 csomag összeállítása

Ha egyetlen bináris csomagot 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 csomag 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 programcsomag 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-csomag kiszolgálót.

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

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

Pillanatképek a Portage csomagkezelő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 csomagok 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 csomag szerverkönyvtár.

A fájlok a csomagkönyvtárból a célkönyvtárban másolódnak. Egy Packages fájl ezután létrejön a bináris csomagkiszolgáló szá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 csomagszerver számítógép 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 csomag formátum megértése

XPAK formátum

A Portage által létrehozott XPAK formátumú bináris csomagok 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 csomag 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

The .xpak file can be examined using the qxpak utility.

A tartalom felsorolásához:

user $qxpak -l <package>.xpak

A következő parancs kicsomagolja a USE nevű fájlt, amely tartalmazza a csomag 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 csomagok 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 csomag 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 csomagkönyvtár a 2-es verziót használja) az első bináris csomagkönyvtár-elrendezéshez (1. verzió) képest. Az 1-es verzióban az összes bináris csomag 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 csomagokhoz.

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

• Binary package quickstart — using the fully-supported Gentoo binary package host for amd64 and arm64 with the settings the packages are compiled with
• Emerge — Portage csomagkezelő fő parancssori felülete
• Portage — Gentoo hivatalos csomagkezelője és terjesztési (disztribúciós) rendszere
• Project:Binhost — aims to provide readily installable, precompiled packages for a subset of configurations, via central binary package hosting

Külső források

quickpkg man súgó.