PKGBUILD (Magyar)

Fordítás állapota: Ez az oldal az angol PKGBUILD című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.05.16. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb módosítások, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.

További oldalak az adott témakörben

• Arch build system (Magyar)
• Arch package guidelines (Magyar)
• Arch User Repository (Magyar)
• .SRCINFO (Magyar)

Ez a cikk azokról a változókról szól, amelyeket a karbantartó (maintainer) meg tud határozni egy PKGBUILD szkriptfájlban. A PKGBUILD függvényeivel kapcsolatban és általában a szoftvercsomagok létrehozásával kapcsolatban tekintse meg a Szotvercsomagok létrehozása című oldalt. Olvassa el továbbá a PKGBUILD(5) man súgót.

A PKGBUILD egy Bash szkriptfájl, amely az Arch Linux szoftvercsomagok létrehozásához szükséges információkat tartalmazza.

Az Arch Linux szoftvercsomag-archívumfájlok a makepkg segédprogrammal készülnek. (A szoftvercsomag-archívumfájl lényegében egy közönséges tömörített fájl). Amikor a makepkg fut, megkeresi az aktuális könyvtárban a PKGBUILD fájlt, és követi annak utasításait azért, hogy lefordítsa vagy más módon beszerezze a fájlokat a szoftvercsomag-archívumfájl létrehozása céljából — pkgname.pkg.tar.zst. Az elkészült szoftvercsomag-archívumfájl a számítógép által binárisan futtatható fájlokat, és telepítési utasításokat tartalmaz. A létrehozott szoftvercsomag-archívumfájlok azonnal feltelepíthetők a számítógépre a pacman szoftvercsomag-kezelő segítségével.

A kötelező változók a pkgname, pkgver, pkgrel és arch. A license változó nem feltétlenül szükséges a szoftvercsomag létrehozásához, de ajánlott minden olyan PKGBUILD szkriptfájl esetében, amelyet másokkal megosztanak, mivel a makepkg figyelmeztetést ad amikor nincs jelen ez a változó.

Általános gyakorlat, hogy a változókat a PKGBUILD fájlban ugyanabban a sorrendben határozzák meg, mint ahogyan ebben a cikkben szerepelnek. Ez azonban nem kötelező.

Tipp

• Használja a namcap segédprogramot a PKGBUILD szkriptfájlok ellenőrzésére annak érdekében, hogy kiszűrje a gyakori szoftvercsomagolási hibákat.
• Használja a shellcheck(1) szegédprogramot a PKGBUILD szkriptfájlok ellenőrzésére annak érdekében, hogy kiszűrje a gyakori szkriptelési hibákat. Tekintse meg a SC2034, SC2154 és SC2164 leírásokat:

shellcheck --shell=bash --exclude=SC2034,SC2154,SC2164 PKGBUILD

• A termux-language-server^AUR egy nyelvi szervert biztosít a PKGBUILD, makepkg.conf stb. számára.

Példa gyanánt tekintse meg a .proto fájlokat a /usr/share/pacman/ könyvtárban.

Szoftvercsomag neve

pkgbase

Amikor Ön szokványos szoftvercsomagokat hoz létre, nem kötelező megadni ezt a változót a PKGBUILD fájlban: Értéke alapértelmezés szerint megegyezik a #pkgname értékével.

Amikor Ön egy osztott szoftvercsomagot készít, ezt a változót szándékosan meg lehet adni, hogy meg legyen határozva az, hogy milyen névvel hivatkozzon a szoftvercsomagok csoportjára a makepkg kimenetében, valamint a csak forrásokat tartalmazó tar tömörített fájlok elnevezésében. Az érték nem kezdődhet kötőjellel. Ha nincs megadva, akkor az érték alapértelmezés szerint a pkgname tömb első elemére fog beállni.

Az osztott szoftvercsomagok minden beállítása és direktívája alapértelmezés szerint a PKGBUILD fájlban megadott globális értékeket veszi át. Ennek ellenére a következőket felül lehet írni az egyes osztott szoftvercsomagok csomagolási függvényében: #pkgdesc, #arch, #url, #license, #groups, #depends, #optdepends, #provides, #conflicts, #replaces, #backup, #options, #install és #changelog.

pkgname

A szoftvercsomag neve lehet egyetlen név, például pkgname=jezus, vagy osztott szoftvercsomagok esetén egy névtömb, például pkgname=(jezus krisztus). A szoftvercsomagnevek kizárólag kisbetűs alfanumerikus karakterekből és a következő jelekből állhatnak: @._+- (kukac, pont, aláhúzás, plusz, kötőjel). A nevek nem kezdődhetnek kötőjellel vagy ponttal. A következetesség érdekében a pkgname értékének meg kell egyeznie a szoftver tar forrásfájljának a nevével: Ha például a szoftver neve jezuskrisztus-2.5.tar.gz, akkor használja a pkgname=jezuskrisztus formát.

Verzió

pkgver

A szoftvercsomag verziója.

Ez ugyanaz kell, hogy legyen, mint a szoftver eredeti szerzője által közzétett verzió. Tartalmazhat betűket, számokat, pontokat és aláhúzásokat, de nem tartalmazhat kötőjelet (-). Ha a szoftver szerzője kötőjelet használ, akkor azt aláhúzásra (_) kell cserélni. Ha a pkgver változó később felhasználásra kerül a PKGBUILD fájlban, akkor az aláhúzás könnyen helyettesíthető kötőjellel. Például: source=("${pkgname}-${pkgver//_/-}.tar.gz").

Megjegyzés Ha az eredeti fejlesztő időbélyeg-alapú verziószámozást használ, például 30102014, akkor ügyeljen rá, hogy Ön a fordított dátumot használja, azaz 20141030 (ISO 8601 formátum). Ellenkező esetben nem fog újabb verzióként megjelenni.

Tipp

• A ritkán használt értékek sorrendje tesztelhető a vercmp(8) segítségével, amelyet a pacman szoftvercsomag biztosít.
• A makepkg automatikusan frissítheti ezt a változót egy pkgver() függvény definiálásával a PKGBUILD fájlban. Részletekért tekintse meg a VCS package guidelines#A pkgver() függvény című leírást.

Továbbá, tekintse meg az Arch package guidelines#Irányelvek a szoftvercsomagok verziószámának és kiadási számának meghatározásához című leírást is.

pkgrel

A kiadási szám. Ez általában egy pozitív egész szám, amely lehetővé teszi az egymást követő szoftvercsomag-létrehozások megkülönböztetését ugyanazon szoftvercsomag verzióján belül. Ahogy javítások és további funkciók kerülnek hozzáadásra a PKGBUILD fájlhoz, amelyek befolyásolják a létrejövő szoftvercsomagot, a pkgrel értékét növelni kell 1‑gyel. Amikor a szoftver új verziója megjelenik, ezt az értéket vissza kell állítani 1‑re. Kivételes esetekben más formátumok is használatban lehetnek, például major.minor.

Továbbá, tekintse meg az Arch package guidelines#Irányelvek a szoftvercsomagok verziószámának és kiadási számának meghatározásához című leírást is.

epoch

Arra szolgál, hogy a szoftvercsomagot újabbnak lehessen tekinteni minden korábbi verziónál, amelynek alacsonyabb az epoch értéke. Ennek az értéknek nemnegatív egész számnak kell lennie. Az alapértelmezett érték 0. Akkor használják, amikor egy szoftvercsomag verziószámozási sémája megváltozik (vagy alfanumerikus), és ez megtöri a normál verzió-összehasonlítás logikáját. Például:

pkgver=5.13
pkgrel=2
epoch=1

1:5.13-2

Tekintse meg a pacman(8) man súgót a verzió összehasonlításokkal kapcsolatos további információkért.

Figyelmeztetés Az epoch kizárólag akkor használható, amikor erre feltétlenül szükség van.

Általános

pkgdesc

A szoftvercsomag leírása. Ajánlott, hogy legfeljebb 80 karakter hosszú legyen, és ne tartalmazza a szoftvercsomag nevét önmagára hivatkozó módon, kivéve, amikor az alkalmazás neve eltér a szoftvercsomag nevétől. Például használja a pkgdesc='Text editor for X11' formát, ahelyett, hogy a pkgdesc='Nedit is a text editor for X11' formát alkalmazná.

Emellett fontos, hogy bölcsen használja a kulcsszavakat, ezzel növelve annak esélyét, hogy a szoftvercsomag megjelenjen a releváns keresési lekérdezésekben.

arch

Az arch tömb a PKGBUILD fájlban azt határozza meg, hogy mely processzor‑architektúrákra hozható létre a szoftvercsomag és mely processzor‑architektúrákon futtatható a szoftvercsomag. Ha egy architektúra nincs felsorolva a tömbben, akkor a makepkg nem engedi a szoftvercsomag forráskódból történő lefordítását azon a rendszeren. Az arch hivatalosan csak az x86_64 architektúrát támogatja, de más projektek más architektúrákat is támogathatnak. Például az Arch Linux 32 támogatja a i686 és pentium4 architektúrákat, míg az Arch Linux ARM támogatja a armv7h (armv7 hardfloat) és aarch64 (armv8 64-bit) architektúrákat.

Kétféle értéket használhat a tömb:

• Az arch=(any) azt jelzi, hogy a szoftvercsomag bármely architektúrán létrehozható, és a létrehozás után architektúrafüggetlen a forráskódból lefordított állapotában (általában shell szkriptek, betűtípusok, témák, sokféle kiterjesztés, Java programok stb.).
• Az arch=(...) egy vagy több architektúrával (de nem any) azt jelzi, hogy a szoftvercsomag bármely megadott architektúrára forráskódból lefordítható, de a kódfordítás után architektúrafüggő lesz. Ezeknél a szoftvercsomagoknál meg kell adni minden olyan architektúrát, amelyet a PKGBUILD hivatalosan támogat. A hivatalos szoftvercsomag-tárolóban és az AUR szoftvercsomagoknál ez az arch=('x86_64') architektúrát jelenti. Opcionálisan az AUR szoftvercsomagok dönthetnek úgy, hogy további ismerten működő architektúrákat is támogatnak.

A célarchitektúra a szoftvercsomag-létrehozás során a CARCH változóval érhető el.

url

A csomagolt szoftver hivatalos webhelyének URL-címe.

license

A licenc ami alatt a szoftver terjesztve van. Az Arch Linux SPDX licencazonosítókat használ. Minden licenchez tartoznia kell egy megfelelő bejegyzésnek a /usr/share/licenses/ könyvtárban.

A gyakori licencekhez (például GPL-3.0-or-later) a licenses szoftvercsomag biztosítja az összes megfelelő fájlt. A szoftvercsomag alapértelmezés szerint telepítve van, mivel a base meta szoftvercsomag függősége, és a fájlok megtalálhatók a /usr/share/licenses/spdx/ könyvtárban. Egyszerűen hivatkozzon a licencre az SPDX azonosítók listájából származó SPDX licencazonosító használatával.

Az olyan licenccsaládok, mint a BSD vagy az MIT, szigorúan véve nem egyetlen licencet jelentenek, és minden egyes változat külön licencfájlt igényel. A license változóban közös SPDX azonosítóval hivatkozzon rájuk (például BSD-3-Clause vagy MIT), majd adja meg a megfelelő fájlt úgy, mintha egyedi licenc lenne.

Az egyedi licencek esetében az azonosítónak LicenseRef-license-name vagy custom:license-name formátumúnak kell lennie, amennyiben azokat nem fedik le a fent említett közös licenccsaládok. A megfelelő licencszöveget a /usr/share/licenses/pkgname könyvtárba kell elhelyezni. A fájl telepítéséhez a következő kódrészlet használható a package() szakaszban:

install -Dm644 LICENSE -t "${pkgdir}/usr/share/licenses/${pkgname}/"

Megjegyzés A pkgdir változót a makepkg határozza meg. További információért tekintse meg a PKGBUILD(5) § PACKAGING FUNCTIONS man súgót.

A több licenc kombinálása vagy kivételek hozzáadása az SPDX szintaxis szerint történjen. Például egy szoftvercsomag, amelyet vagy GNU/GPL 2.0 vagy GNU/LGPL 2.1 alatt adnak ki, használhatja a 'GPL-2.0-or-later OR LGPL-2.1-or-later' kifejezést, egy Apache 2.0 licenc alatt kiadott szoftvercsomag LLVM kivétellel a 'Apache-2.0 WITH LLVM-exception' kifejezést, míg egy olyan szoftvercsomag, amelynek egy része BSD 3 klauzula alatt, más része GNU/LGPL 2.1 alatt, és néhány GNU/GPL 2.0 alatt van kiadva, a 'BSD-3-Clause AND LGPL-2.1-or-later AND GPL-2.0-or-later' kifejezést használhatja [1]. Fontos, hogy ez egyetlen karakterlánc legyen, tehát a teljes kifejezést idézőjelek közé kell tenni. 2023 novemberétől az SPDX kivételek listája korlátozott, így általában az egyedi licenc útvonalat kell használni.

Ha problémák merülnek fel az SPDX azonosítókkal kapcsolatban, akkor az átmeneti időszakban elfogadható a régi azonosítók használata — vagyis a könyvtárak nevei a /usr/share/licenses/common útvonalon.

Tekintse meg a Nem szabadon terjeszthető alkalmazások csomagolásának irányelvei című oldalt.

További információk és nézőpontok a szabad és nyílt forráskódú szoftverlicencekkel kapcsolatban az alábbi oldalakon találhatók:

• Wikipedia:Free software license
• Wikipedia:Comparison of free and open-source software licenses
• A Legal Issues Primer for Open Source and Free Software Projects
• GNU Project - Various Licenses and Comments about Them
• Debian - License information
• Open Source Initiative - Licenses by Name

groups

A szoftvercsomagcsoport, amelyhez a szoftvercsomag tartozik. Amikor például a plasma telepítésre kerül, akkor az összes, ebbe a csoportba tartozó szoftvercsomagot feltelepíti a számítógépre.

Függőségek

Megjegyzés További architektúraspecifikus tömbök adhatók hozzá az architektúra nevének aláhúzásjel és név hozzáfűzésével, pl. optdepends_x86_64=().

depends

Egy szoftvercsomagtömb, amelyet telepíteni kell ahhoz, hogy a szoftver létrejöjjön és fusson. Azok a szoftvercsomag-függőségek, amelyek a package() függvényen belül vannak meghatározva, csak a szoftver futtatásához szükségesek.

A verziókorlátozások megadhatók összehasonlító operátorokkal. Például: depends=('foobar>=1.8.0'). Ha több korlátozásra van szükség, akkor a szoftvercsomag-függőséget minden egyes esethez meg lehet ismételni. Például: depends=('foobar>=1.8.0' 'foobar<2.0.0').

A depends tömbnek minden közvetlen, első szintű szoftvercsomag-függőséget tartalmaznia kell, még akkor is, ha néhány már tranzitívan deklarálva van. Például, ha egy foo szoftvercsomag függ mind a bar, mind a baz szoftvercsomagtól, és a bar szoftvercsomag viszont szintén függ a baz szoftvercsomagtól, akkor nem kívánt viselkedéshez vezethet, ha a bar többé nem húzza be függőségként a baz szoftvercsomagot. A pacman szoftvercsomag-kezelő nem fogja kikényszeríteni a baz telepítését azon rendszereken, amelyek újonnan telepítik a foo szoftvercsomagot, vagy amelyek eltávolították az elárvult szoftvercsomagokat, és a foo futásidőben összeomlik vagy más módon hibásan fog működni.

Bizonyos esetekben ez nem szükséges, és fel is tüntethető, de nem kötelező. Például a glibc nem távolítható el, mivel minden rendszernek szüksége van valamilyen C függvénykönyvtárra, vagy a python egy olyan szoftvercsomag esetében, amely már függ egy másik python- modultól, hiszen a második modul definíció szerint függ a python-tól, és soha nem szűnhet meg annak függőségként való behúzása.

A szoftvercsomag-függőségeknek általában tartalmazniuk kell a szoftvercsomag minden opcionális funkciójának létrehozásához szükséges követelményeket. Alternatív megoldásként minden olyan funkciót, amelynek függőségei nincsenek feltüntetve, kifejezetten le kell tiltani egy beállításopcióval. Ennek elmulasztása olyan szoftvercsomagok létrejöttéhez vezethet, amelyeknél az "automatikus függőségek" futásidejű opcionális funkciói létrehozás közben kiszámíthatatlanul engedélyeződnek tranzitív függőségek vagy a build gépen telepített, nem kapcsolódó szoftverek miatt. Ám ezek nem tükröződnek a szoftvercsomag függőségeiben.

Ha a szoftvercsomag-függőség neve függvénykönyvtárnak tűnik, pl. depends=(libfoobar.so), akkor a makepkg megpróbálja megkeresni a létrehozott szoftvercsomagban azt a bináris fájlt, amely a függvénykönyvtártól függ, és hozzáfűzi a bináris fájl által igényelt soname verziót. A verzió manuális úton történő hozzáfűzése letiltja az automatikus felismerést, pl. depends=('libfoobar.so=2').

makedepends

Egy olyan szoftvercsomagtömb, amely csak a szoftvercsomag létrehozásához szükséges. A minimális szoftvercsomag-függőségi verzió ugyanabban a formátumban adható meg, mint a depends tömbben. A depends tömbben szereplő szoftvercsomagok implicit módon szükségesek a szoftvercsomag létrehozásához, ezért itt nem szabad ismételten megadni őket.

Megjegyzés

• A base-devel szoftvercsomagról feltételezhető, hogy már fel van telepítve a számítógépre, amikor a makepkg segítségével Ön szoftvercsomagot hoz létre. Ennek a szoftvercsomagnak a szoftvercsomag-függőségeit nem szabad belefoglalni a makedepends tömbbe.
• Amennyiben Ön VCS forrásokat használ, ne felejtse el belefoglalni a megfelelő VCS segédprogramot (git, subversion, cvs, ...).

Tipp Használja a pactree -rsud1 package | grep base-devel parancsot annak ellenőrzésére, hogy egy adott szoftvercsomag közvetlen függősége-e a base-devel szoftvercsomagnak. (Ehhez szükséges a pacman-contrib szoftvercsomag megléte a számítógépen).

checkdepends

Egy szoftvercsomagtömb, amelyre a szoftvernek szüksége van a tesztkészlet futtatásához, de futásidőben nincs rá szükség. Az ebben a listában szereplő szoftvercsomagok ugyanazt a formátumot követik, mint a depends. Ezeket a szoftvercsomag-függőségeket egyedül akkor veszi figyelembe a rendszer, amikor a check() függvény jelen van, és a makepkg futtatni fogja.

Megjegyzés A base-devel szoftvercsomagról feltételezve van, hogy már telepítve van a számítógépre, amikor a makepkg segítségével Ön szoftvercsomagot hoz létre. Ennek a szoftvercsomagnak a szoftvercsomag-függőségeit nem szabad belefoglalni a checkdepends tömbbe.

optdepends

Egy szoftvercsomagtömb, amelyre a szoftver működéséhez nincs szükség, de további funkciókat biztosít. Ez azt jelentheti, hogy nem minden, a szoftvercsomag által biztosított végrehajtható fájl működni fog a megfelelő optdepends nélkül.[2] Ha a szoftver több alternatív szoftvercsomag-függőséggel is működik, akkor itt mindegyik felsorolható a depends tömbben történő felsorolás helyett.

Az extra funkciók rövid leírását, amelyet minden egyes optdepend biztosít, szintén fel kell jegyezni:

optdepends=('cups: printing support'
            'sane: scanners support'
            'libgphoto2: digital cameras support'
            'alsa-lib: sound support'
            'giflib: GIF images support'
            'libjpeg: JPEG images support'
            'libpng: PNG images support')

Szoftvercsomagok kapcsolatai

Megjegyzés Az architektúraspecifikus tömbök további példányai hozzáadhatók azáltal, hogy aláhúzásjelet és az architektúra nevét illeszti hozzá. Például: conflicts_x86_64=().

provides

Egy további szoftvercsomagokból álló tömb, amelyeket a szoftver szolgáltatásként biztosít, beleértve a virtuális szoftvercsomagokat, mint például a cron vagy a sh, valamint az összes külső megosztott függvénykönyvtárat. Azonos elemet biztosító szoftvercsomagok egymás mellett is telepíthetők, kivéve, ha legalább egyikük használja a conflicts tömböt.

Megjegyzés

• A szoftvercsomag által biztosított verziót meg kell említeni (pkgver és adott esetben a pkgrel), arra az esetre, ha a szoftverre hivatkozó szoftvercsomagoknak szükségük lenne rá. Például Önnek a következőt kell használnia egy módosított qt szoftvercsomag 3.3.8 verziójával, qt-foobar néven: provides=('qt=3.3.8'). A verziószám elhagyása azt eredményezné, hogy a qt adott verzióját igénylő szoftvercsomag-függőségek meghiúsulnak.
• Ne adja hozzá a pkgname változót a provides tömbhöz, mivel ez automatikusan megtörténik.

conflicts

Azon szoftvercsomagok tömbje, amelyek ütköznek a szoftvercsomaggal, vagy problémát okoznak számára, ha telepítve vannak. Az összes ilyen szoftvercsomagot és az ezt az elemet biztosító szoftvercsomagokat el kell távolítani. Az ütköző szoftvercsomagok verziótulajdonságai ugyanabban a formátumban adhatók meg, mint a depends tömb esetében.

Vegye figyelembe, hogy az ütközések ellenőrzése a pkgname ellen, valamint a provides tömbben megadott nevekkel szemben is megtörténik. Ezért, ha az Ön szoftvercsomagja biztosít egy foo funkciót, akkor a foo megadása a conflicts tömbben ütközést fog okozni az Ön szoftvercsomagja és minden más szoftvercsomag között, amely tartalmazza a foo elemet a saját provides tömbjében (vagyis nincs szükség az összes ilyen ütköző szoftvercsomagnév megadására az Ön conflicts tömbjében). Vegyünk egy konkrét példát:

• A netbeans implicit módon biztosítja a netbeans elemet magán a pkgname néven keresztül.
• Egy hipotetikus netbeans-cpp szoftvercsomag biztosítaná a netbeans elemet, és ütközik a netbeans szoftvercsomaggal.
• Egy hipotetikus netbeans-php szoftvercsomag biztosítaná a netbeans elemet, és ütközik a netbeans szoftvercsomaggal, de nem szükséges kifejezetten ütköznie a netbeans-cpp szoftvercsomaggal, mivel az ugyanazt a funkciót biztosító szoftvercsomagok implicit módon ütköznek egymással.

Amikor a szoftvercsomagok ugyanazt a funkciót biztosítják a provides tömbön keresztül, különbség van aközött, hogy az alternatív szoftvercsomag szándékosan hozzá van-e adva a conflicts tömbhöz vagy nincs hozzáadva. Ha a conflicts tömb szándékosan deklarálva van, akkor az ugyanazt a funkciót biztosító két szoftvercsomag alternatívnak lesz tekintve. Ha a conflicts tömb hiányzik, akkor az ugyanazt a funkciót biztosító két szoftvercsomag esetlegesen együtt létezőnek lesz tekintve. A szoftvercsomag-készítőknek mindig figyelmen kívül kell hagyniuk a provides változó tartalmát annak eldöntésekor, hogy deklaráljanak-e conflicts változót vagy sem.

replaces

Azon elavult szoftvercsomagok tömbje, amelyeket a szoftvercsomag helyettesít, pl. a wireshark-qt a replaces=('wireshark') használatával. Szinkronizáláskor a pacman azonnal lecserél egy feltelepített szoftvercsomagot, amint a szoftvercsomag-tárolókban talál egy másik szoftvercsomagot, amelynek replaces mezője egyezik. Amennyiben Ön egy már létező szoftvercsomag alternatív verzióját adja meg, vagy az AUR szoftvercsomag-tárolóba tölti fel, akkor használja a conflicts és provides tömböket, amelyek csak akkor kerülnek kiértékelésre, amikor a konfliktusos szoftvercsomag tényleges feltelepítése történik.

Egyéb

backup

Egy fájlokból álló tömb, amely felhasználó által készített módosításokat tartalmazhat, és amelyeket egy szoftvercsomag frissítése vagy eltávolítása során meg kell őrizni, elsősorban a /etc könyvtárban található beállításfájlokhoz készült. Ha ezek a fájlok változatlanok ahhoz képest, ahogyan a szoftvercsomaggal együtt kerülnek szállításra, akkor frissítés vagy eltávolítás során normál fájlokként törlésre kerülnek vagy lecserélődnek.

Az ebben a tömbben lévő fájloknak relatív útvonalakat kell használniuk a kezdő perjel (/) nélkül (pl. etc/pacman.conf, a /etc/pacman.conf helyett). A backup tömb nem támogatja az üres könyvtárakat vagy a "*" jelhez hasonló helyettesítő karaktereket.

Frissítéskor az új verziók fájl.pacnew néven kerülhetnek mentésre, hogy elkerüljék egy már létező és korábban a felhasználó által módosított fájl felülírását. Hasonlóan, a szoftvercsomag eltávolításakor a felhasználó által módosított fájlok fájl.pacsave néven kerülnek megőrzésre, kivéve, ha a szoftvercsomag eltávolítása a pacman -Rn paranccsal történt.

Tekintse meg a Pacnew és Pacsave fájlok című oldalt.

options

Ez a tömb lehetővé teszi a makepkg alapértelmezett viselkedésének felülbírálását, amely a /etc/makepkg.conf fájlban van meghatározva. Egy opció beállítása érdekében adja meg az opció nevét a tömbben. Egy opció letiltása érdekében helyezzen az opció elé egy ! jelet.

A rendelkezésre álló opciók teljes listája a PKGBUILD(5) § OPTIONS AND DIRECTIVES man súgóban található meg.

install

A szoftvercsomagba belefoglalandó .install szkript neve.

A pacman képes egy szoftvercsomag-specifikus szkript tárolására és végrehajtására, amikor egy szoftvercsomagot telepít, eltávolít vagy frissít. A szkript az alábbi függvényeket tartalmazza, amelyek különböző időpontokban futnak:

• pre_install — A szkript közvetlenül a fájlok kibontása előtt fut le. Egy argumentum kerül átadásra: Az új szoftvercsomag verziója.
• post_install — A szkript közvetlenül a fájlok kibontása után fut le. Itt helyezendők el azok a további megjegyzések, amelyeket a szoftvercsomag telepítése után kell kiírni. Egy argumentum kerül átadásra: Az új szoftvercsomag verziója.
• pre_upgrade — A szkript közvetlenül a fájlok kibontása előtt fut le. Két argumentum kerül átadásra a következő sorrendben: Az új szoftvercsomag verziója, a régi szoftvercsomag verziója.
• post_upgrade — A szkript közvetlenül a fájlok kibontása után fut le. Két argumentum kerül átadásra a következő sorrendben: Az új szoftvercsomag verziója, a régi szoftvercsomag verziója.
• pre_remove — A szkript közvetlenül a fájlok eltávolítása előtt fut le. Egy argumentum kerül átadásra: A régi szoftvercsomag verziója.
• post_remove — A szkript közvetlenül a fájlok eltávolítása után fut le. Egy argumentum kerül átadásra: A régi szoftvercsomag verziója.

Mindegyik függvény chroot környezetben fut, a pacman telepítési könyvtárán belül. Részletekért tekintse meg ezt a témát.

Tipp

• Egy prototípus .install fájl elérhető a /usr/share/pacman/proto.install elérési útvonalon.
• A pacman#Automatikus műveletindító fájlok hasonló funkcionalitást biztosítanak.

Megjegyzés Ne fejezze be a szkriptet exit paranccsal. Ez megakadályozná a benne található függvények végrehajtását.

changelog

A szoftvercsomag változásnaplójának neve. A telepített szoftvercsomag változásnaplójának megtekintése érdekében a következő parancsot kell futtatni (amelyek a telepített szoftvercsomag rendelkeznek változásnaplófájllal):

$ pacman -Qc pkgname

Források

source

Egy, a szoftvercsomag létrehozásához szükséges fájlokból álló tömb. Tartalmaznia kell a szoftver forrásának helyét, amely a legtöbb esetben egy teljes HTTP vagy FTP URL. A korábban beállított pkgname és pkgver változók itt hatékonyan használhatók. Például: source=("https://example.com/${pkgname}-${pkgver}.tar.gz").

A fájlok a PKGBUILD szkriptfájlt tartalmazó könyvtárban is megadhatók, és nevük hozzáadható ehhez a tömbhöz. A tényleges kódfordítási folyamat megkezdése előtt a tömbben hivatkozott összes fájl letöltésre kerül vagy ellenőrzésre kerül a meglétük, és ha bármelyik hiányzik, akkor a makepkg nem folytatja a műveletet.

A .install fájlokat a makepkg automatikusan felismeri, és nem szabad őket a source tömbbe felvenni. A source tömbben szereplő .sig, .sign vagy .asc kiterjesztésű fájlokat a makepkg PGP-aláírásként ismeri fel, és automatikusan felhasználja a megfelelő forrásfájl integritásának ellenőrzéséhez.

Figyelmeztetés A letöltött forrásfájl nevének egyedinek kell lennie, mivel a SRCDEST könyvtár minden szoftvercsomag esetén ugyanaz lehet. Például a projekt verziószámának fájlnévként való használata ütközhet más, azonos verziószámú projektekkel. Ebben az esetben az alternatív, egyedi használható fájlnév a source=('unique_package_name::file_uri') szintaxissal adható meg. Például: source=("${pkgname}-${pkgver}.tar.gz::https://github.com/coder/program/archive/v${pkgver}.tar.gz").

Tipp

• További architektúra-specifikus tömbök adhatók hozzá az aláhúzás és az architektúra nevének hozzáfűzésével. Például: source_x86_64=(). Ennek megfelelően léteznie kell egy integritási tömbnek is ellenőrzőösszegekkel. Például: sha256sums_x86_64=().
• Egyes szerverek korlátozhatják a letöltést az ügyfél User-Agent karakterláncának szűrésével vagy egyéb típusú korlátozásokkal, amely korlátozások a DLAGENTS használatával megkerülhetők.
• A file:// URL használható a helyi számítógép fájlrendszerében lévő könyvtár vagy fájl megadására. Például egy helyi Git tároló így adható meg: "${pkgname}::git+file:///elérési/út/a/tárolóhoz".
• A magnet link támogatás hozzáadható a transmission-dlagent^AUR használatával DLAGENT formájában, valamint a magnet:// URI előtag használatával a kanonikus magnet:? helyett.
• Tekintse meg a PKGBUILD(5) § USING VCS SOURCES man súgót és a VCS package guidelines#VCS sources szakaszokat a VCS-specifikus beállítások részleteiért, például egy adott Git fejlesztési ág vagy commit célzásához.

noextract

Egy fájlokból álló tömb, amely a source tömb alatt van felsorolva, és amelyet a makepkg nem szabad, hogy kicsomagoljon az archívum formátumából. Ez használható olyan archívumok esetén, amelyeket a /usr/bin/bsdtar nem tud kezelni, vagy amelyeket változatlan formában kell telepíteni. Amennyiben alternatív kicsomagoló program van használva (például lrzip), akkor azt hozzá kell adni a makedepends tömbhöz, és a prepare() függvény első sorának manuálisan kell kicsomagolnia a forráskódot tartalmazó archívumfájlt. Például:

prepare() {
  lrzip -d source.tar.lrz
}

Vegye figyelembe, hogy míg a source tömb elfogad URL címeket, addig a noextract kizárólag a fájlnév részét fogadja el:

source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')

Annak érdekében, hogy semmi ne legyen kicsomagolva, vegye figyelembe a következőket:

• Ha a source csak egyszerű URL címeket tartalmaz egyéni fájlnevek nélkül, akkor a source tömbben a legutolsó perjel előtt vágja le:

noextract=("${source[@]##*/}")

• Ha a source csak egyéni fájlneveket tartalmazó bejegyzéseket tartalmaz, akkor a source tömböt a :: elválasztó után kell levágni (a firefox-i18n PKGBUILD egy korábbi verziójából átvéve):

noextract=("${source[@]%%::*}")

Megjegyzés Ha egy archívumfájl sok felső szintű fájlt tartalmaz, akkor fennáll a veszélye annak, hogy más forráskódot tartalmazó archívumfájlokból kicsomagolt fájlokat nem kívánt módon felülír. Ha ez a helyzet, akkor fontolja meg, hogy hozzáadja a noextract tömbhöz, és manuálisan csomagolja ki egy alkönyvtárba.

validpgpkeys

PGP ujjlenyomatok tömbje. Ha használva van, akkor a makepkg csak az itt felsorolt kulcsokból származó aláírásokat fogadja el, és figyelmen kívül hagyja a kulcstartóban található megbízhatósági értékeket. Ha a forrásfájlt egy al kulccsal lett aláírva, akkor a makepkg továbbra is a főkulcsot fogja használni az összehasonlításhoz.

Egyedül teljes ujjlenyomatok fogadhatók el. Nagybetűsnek kell lenniük, és nem tartalmazhatnak szóköz karaktereket.

Megjegyzés Használja a gpg --list-keys --fingerprint KEYID parancsot annak megállapítására, hogy mi az adott kulcs megfelelő ujjlenyomata.

További információkért kérjük, hogy olvassa el a makepkg#Szoftvercsomag aláírásának az ellenőrzése című leírást.

Integritás

Ezek a változók olyan tömbök, amelyek elemei ellenőrzőösszeg-karakterláncok, és a megfelelő fájlok integritásának ellenőrzésére lesznek használva a source tömbben. Szúrja be a SKIP értéket egy adott fájlhoz, és annak ellenőrzőösszege nem lesz ellenőrizve.

Az ellenőrzőösszeg típusa és értékei mindig az upstream által megadottak legyenek, például a kiadási bejelentésekben szereplők. Ha több típus is elérhető, akkor a legerősebb ellenőrzőösszeg részesítendő előnyben (a leginkább előnyöstől a legkevésbé előnyösig): b2, sha512, sha384, sha256, sha224, sha1, md5, ck. Ez biztosítja legjobban a letöltött fájlok integritását, a upstream bejelentéstől a szoftvercsomag létrehozásáig.

Megjegyzés Továbbá, amikor az upstream digitális aláírásokat tesz elérhetővé, az aláírásfájlokat hozzá kell adni a source tömbhöz, a PGP-kulcs ujjlenyomatát pedig a validpgpkeys tömbhöz kell hozzáadni. Ez lehetővé teszi a fájlok hitelesítését a szoftvercsomag létrehozási folyamata során.

Ezeknek a változóknak az értékei automatikusan előállíthatók a makepkg -g/--geninteg kapcsolójával, majd általában a makepkg -g >> PKGBUILD paranccsal kerülnek hozzáfűzésre. A pacman-contrib szoftvercsomagból származó updpkgsums(8) parancs képes frissíteni a változókat, bárhol is legyenek azok a PKGBUILD fájlban. Mindkét segédprogram a PKGBUILD fájlban már beállított változót fogja használni, vagy ha egyik sincs beállítva, akkor visszatér a sha256sums változóra.

A használandó fájlintegritás-ellenőrzések a /etc/makepkg.conf fájlban található INTEGRITY_CHECK beállítással adhatók meg. Tekintse meg a makepkg.conf(5) man súgót.

Megjegyzés További architektúraspecifikus tömbök adhatók hozzá egy aláhúzásjel és az architektúra nevének hozzáfűzésével. Például: sha256sums_x86_64=().

b2sums

Egy BLAKE2b ellenőrzőösszegeket tartalmazó tömb 512 bites kivonatmérettel.

sha512sums, sha384sums, sha256sums, sha224sums

Egy SHA-2 ellenőrzőösszegeket tartalmazó tömb rendre 512, 384, 256 és 224 bites kivonatméretekkel. Ezek közül a sha256sums a leggyakoribb.

sha1sums

A source tömbben felsorolt fájlok 160 bites SHA-1 ellenőrzőösszegeit tartalmazó tömb.

md5sums

Egy 128 bites MD5 ellenőrzőösszeg tömbje a source tömbben felsorolt fájlokról.

cksums

A source tömbben felsorolt fájlok CRC32 ellenőrzőösszegeit tartalmazó tömb (a UNIX-szabvány szerinti cksum alapján).