PKGBUILD (Magyar) - ArchWiki

Jump to content

# PKGBUILD (Magyar)

From ArchWiki
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-serverAUR 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

This article or section is a candidate for merging with Arch package guidelines#licenses.

Notes: A PKGBUILD formátum nem kényszerít ki szoftvercsomagolási szabályzatot. (Discuss in Talk:PKGBUILD (Magyar))

This article or section needs expansion.

Reason: Adjon hozzá több részletet a ebből a leírásból. (Discuss in Talk:PKGBUILD (Magyar))

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')`.

This article or section is a candidate for merging with Arch package guidelines.

Notes: A PKGBUILD formátum nem kényszerít ki szoftvercsomagolási szabályzatot. (Discuss in Talk:PKGBUILD (Magyar))

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-dlagentAUR 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).

Category:

- Package development (Magyar)

Hidden categories:

- Pages or sections flagged with Template:Merge
- Pages or sections flagged with Template:Expansion

PKGBUILD (Magyar)
Add topic