Arch package guidelines (Magyar)

Fordítás állapota: Ez az oldal az angol Arch package guidelines című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.05.13. 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.

Amikor Ön szoftvercsomagokat készít az Arch Linux számára, tartsa be az alábbi szoftvercsomagolási irányelveket. Különösen akkor tegye ezt, amikor új szoftvercsomagot kíván beküldeni az Arch Linux közösségnek. Továbbá, tekintse meg a PKGBUILD(5) és makepkg(8) című man súgókat is.

A többi szoftvercsomagolási irányelvet tartalmazó oldalon nincsenek megismételve a jelen oldalon felsorolt fontos pontok. Ezek a konkrét irányelvek a lentebb felsorolt szabványok kiegészítéseként szolgálnak.

Tekintse meg a .proto fájlokat a /usr/share/pacman/ könyvtárban, mint PKGBUILD példákat.

Megjegyzés Továbbá, az AUR szoftvercsomag tárolóba beküldött szoftvercsomagoknak meg kell felelniük az AUR beküldési irányelvek előírásainak is.

Szoftvercsomagkészítési etikett

A szoftvercsomagokat soha nem szabad a /usr/local/ könyvtárba telepíteni.

Ne vezessen be új változókat vagy függvényeket a PKGBUILD build szkriptfájlokba, kivéve amikor a szoftvercsomag ezen új változók nélkül nem fordítható le bináris kódra, mivel ezek az újonnan létrehozott változók és függvények esetleg ütközhetnek a makepkg által használt változókkal és függvényekkel.

Ha feltétlenül szükséges egy új változó vagy egy új függvény, akkor a nevét egy aláhúzásjellel (_) kell előtagolni. Például:
```
_customvariable=
```

Kerülje a /usr/libexec/ bármire történő használatát. Használja helyette a /usr/lib/$pkgname/ könyvtárat.

A szoftvercsomag metaadatfájljában található packager mezőt a szoftvercsomag készítője testreszabhatja a megfelelő beállítás módosításával a /etc/makepkg.conf fájlban, vagy alternatívaként felülírhatja azt a ~/.makepkg.conf fájl létrehozásával.

Ne használja a makepkg szubrutinjait (pl. error, msg, msg2, plain, warning), mivel ezek bármikor megváltozhatnak. Adatok kiírásához használja a printf vagy echo parancsokat.

Minden fontos üzenetet meg kell jeleníteni a telepítés során egy .install fájl használatával. Amikor például egy szoftvercsomag további beállítást igényel a működéshez, akkor mellékelni kell az útmutatást.

A szoftvercsomag-függőségek jelentik a leggyakoribb szoftvercsomagolási hibát. Szánjon időt ezek gondos ellenőrzésére, például az ldd(1), ldd --unused --function-relocs és readelf(1) § dynamic parancsok futtatásával dinamikus futtatható állományokon, a szkriptek által igényelt segédprogramok ellenőrzésével vagy a szoftver dokumentációjának áttekintésével. A namcap segédprogram Önnek segítséget nyújthat ebben. Ez a segédprogram képes elemezni mind a PKGBUILD fájlt, mind az elkészült szoftvercsomag tar archívumfájlját, és figyelmeztet a hibás jogosultságokra, hiányzó szoftvercsomag-függőségekre, redundáns szoftvercsomag-függőségekre és más gyakori hibákra.

Azokat a nem kötelező szoftvercsomag-függőségeket, amelyek nem szükségesek a szoftvercsomag futtatásához vagy általános működéséhez, nem szabad a depends tömbben feltüntetni. Ehelyett az információt az optdepends tömbhöz kell hozzáadni:

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

A fenti példa a wine szoftvercsomagból származik. Az optdepends információk automatikusan kiírásra kerülnek telepítés/frissítés során, ezért az ilyen jellegű információkat nem szabad a .install fájlokban tartani.

A szoftvercsomag-leírás készítésekor ne szerepeljen a szoftvercsomag neve önhivatkozó módon. Például a "Nedit is a text editor for X11" egyszerűsíthető "A text editor for X11" formára. Törekedjen arra is, hogy a leírás körülbelül 80 karakter vagy annál rövidebb legyen.

Törekedjen arra, hogy a PKGBUILD fájlban a sorhossz körülbelül 100 karakter alatt maradjon.

Ahol lehetséges, távolítsa el az üres sorokat a PKGBUILD fájlból (provides, replaces stb.) .

Bevett szokás a PKGBUILD mezők eredeti sorrendjének megőrzése a PKGBUILD cikkben megadott sorrend szerint. Ez azonban nem kötelező, mivel ebben a kontextusban az egyetlen követelmény a helyes Bash szintaxis.

Rakja idézőjelbe azokat a változókat, amelyek tartalmazhatnak szóközöket. Például: "$pkgdir" és "$srcdir" .

A szoftvercsomagok integritásának biztosítása érdekében győződjön meg arról, hogy az integritási változók helyes értékeket tartalmaznak. Ezek frissíthetők az updpkgsums(8) segédprogrammal.

Szoftvercsomagok nevei

A szoftvercsomagnevek kizárólag alfanumerikus karaktereket, valamint @, ., _, +, - karaktereket tartalmazhatnak. A nevek nem kezdődhetnek kötőjellel vagy ponttal. Minden betűnek kisbetűsnek kell lennie.
Abban az esetben, amikor feltételezhető, hogy a függvénykönyvtár és szoftvercsomag-függőségei képesek a legfrissebb függvénykönyvtár-verzió használatára az adott upstream kiadásokkal együtt, akkor a szoftvercsomagneveket nem szabad az upstream főverziószámával ellátni (pl. nem használunk libfoo2 nevet, amennyiben az upstream libfoo v2.3.4 nevet használ). Ugyanakkor bizonyos szoftverek vagy szoftvercsomag-függőségek esetén ez nem feltételezhető. Ez a múltban különösen igaz volt olyan widget eszköztárakra, mint a GTK és a Qt. Az ilyen eszköztáraktól függő szoftvereket általában nem lehet egyszerűen átportolni egy új főverzióra. Ezért azokban az esetekben, amikor a szoftver nem képes problémamentesen együtt haladni a szoftvercsomag-függőségeivel, a szoftvercsomagneveknek tartalmazniuk kell a főverzió utótagot (pl. gtk2, gtk3, qt4, qt5). Azokban az esetekben, amikor a szoftvercsomag-függőségek többsége képes a legújabb kiadással együtt haladni, de néhány nem képes együtt haladni (például zárt forráskód, amely libpng12 függvénykönyvtárat vagy hasonlót igényel), akkor az adott szoftvercsomag elavult verziója nevezhető libfoo1 néven, míg az aktuális verzió egyszerűen libfoo.

Irányelvek a szoftvercsomagok verziószámának és kiadási számának meghatározásához

A szoftvercsomag verziója — pkgver — meg kell, hogy egyezzen az eredeti szerző által kiadott szoftververzióval.
Ha szükséges, akkor a verziók tartalmazhatnak betűket. Például: Lehet 2.54BETA32 a verzió.
A verziócímkék nem tartalmazhatnak kötőjeleket. Kizárólag betűket, számokat és pontokat tartalmazhatnak. Ha az upstream verzió kötőjelet tartalmaz, akkor azt aláhúzásjelre kell cserélni.

A szoftvercsomag kiadások — pkgrel — kifejezetten Arch Linux szoftvercsomagokra jellemzőek. Ezek lehetővé teszik a felhasználók számára, hogy megkülönböztessék az újabb és régebbi szoftvercsomag-létrehozásokat. Amikor egy új szoftvercsomag-verzió először jelenik meg, a kiadásszám 1-ről indul. Ezután, ahogy javítások és optimalizációk történnek, a szoftvercsomag újra kiadásra kerül az Arch Linux nyilvánossága számára, és a kiadásszám növekszik.
Amikor egy új verzió jelenik meg, a kiadásszám visszaáll 1-re.
A szoftvercsomag-kiadás címkéire ugyanazok a névhasználati korlátozások vonatkoznak, mint a verziócímkékre.

Szoftvercsomag-függőségek kezelése

Ne támaszkodjon a tranzitív szoftvercsomag-függőségekre a PKGBUILD#Függőségek bármelyikében, mivel ha valamelyik szoftvercsomag-függőség frissül, akkor ezek megszakadhatnak.
Soroljon fel minden közvetlen függvénykönyvtár-függőséget. Azonosításukhoz használható a find-libdeps(1), amely a devtools szoftvercsomagban található meg.

Szoftvercsomagok kapcsolatai

Ne adja hozzá a $pkgname elemet a PKGBUILD#provides szakaszhoz, mivel azt a szoftvercsomag mindig implicit módon biztosítja.
Ne adja hozzá a $pkgname elemet a PKGBUILD#conflicts szakaszhoz, mivel egy szoftvercsomag nem ütközhet önmagával.
Sorolja fel a szoftvercsomag összes külső megosztott függvénykönyvtárát a PKGBUILD#provides szakaszban (pl. 'libsomething.so'). Az azonosításhoz használható a find-libprovides(1), amely a devtools szoftvercsomagban található.

Szoftvercsomagforrások

Ahol csak lehetséges, ott HTTPS protokollt kell használni. (https:// protokollt a tar archívumfájlokhoz. git+https:// protokollt a git-forrásokhoz.)
A forrásokat lehetőség szerint PGP-aláírásokkal kell ellenőrizni. (Ez azt jelentheti, hogy ha a fejlesztő aláírja a commit-okat és tag-eket, de nem írja alá a tar archívumfájlokat, akkor git tag-ből kell létrehozni a forrást a tar archívumfájl helyett.)

The factual accuracy of this article or section is disputed.

Reason: commit# nem szükséges a legújabb pacman szoftvercsomag-kezelőben, mivel támogatott a git-forrásokhoz megfelelő ellenőrzőösszeg. Tekintse meg ezt a linket. A gitea szoftvercsomag is frissítve lett, hogy az alábbi megközelítést használja (Discuss in Talk:Arch package guidelines (Magyar))

Git tag-ből történő létrehozáskor a tag neve helyett a git rev-parse által lekért objektum-hash értéket kell használni:

_tag=1234567890123456789012345678901234567890 # git rev-parse "v$pkgver"
source=(git+https://$url.git?signed#tag=$_tag)

pkgver() {
    cd "$pkgname"
    git describe
}

Ön ennek a megközelítésnek egy példáját a gitea szoftvercsomagban találja meg. Ennek a gyakorlatnak az az oka, hogy a tag-ek erőltetett push segítségével módosíthatók úgy, hogy a mutatott commit megváltozik, ami megváltoztatná a létrehozott szoftvercsomagot. A tag objektum-hash használata biztosítja a források integritását, mert az erőltetett push a tag hash értékét is megváltoztatja. A pkgver() függvény használata megakadályozza, hogy véletlenül megemeljék a pkgver értékét anélkül, hogy frissítenék a _tag értékét is. Tekintse meg a VCS package guidelines#VCS sources című leírást a további információkért a VCS-források formázásáról.

Ne csökkentse a szoftvercsomag biztonságát vagy érvényességét (pl. ellenőrzőösszeg ellenőrzés eltávolításával vagy PGP-aláírás ellenőrzésének megszüntetésével), csak azért mert egy upstream kiadás hibás vagy hirtelen hiányzik egy bizonyos funkció (pl. PGP-aláírás hiányzik egy új kiadáshoz).
A forrásoknak egyedinek kell lenniük a srcdir-ben. (Ez megkövetelheti azok átnevezését letöltéskor. Például: "${pkgname}-${pkgver}.tar.gz::https://${pkgname}.tld/download/${pkgver}.tar.gz" .)
A letöltéshez kerülje a konkrét tükörszerverek (pl. sourceforge) használatát, mivel azok elérhetetlenné válhatnak.
Git objektumok (pl. tag-ek, commit-ok stb.) SSH-kulccsal aláírva ellenőrizhetők egy git parancs segítségével, ahol a gpg.ssh.allowedSignersFile egy fájlra mutat, amely a lehetséges aláírókulcsokat tartalmazza. Egy példáért tekintse meg ezt a linket.

Együttműködés az upstream fejlesztőkkel

A legjobb, általánosan elfogadott gyakorlat az, amikor Ön lehetőség szerint szorosan együttműködik az upstream fejlesztőkkel. (Upstream, tehát a forráskód eredeti karbantartója vagy eredeti fejlesztője). Ez magában foglalja a szoftvercsomag létrehozásával és tesztelésével kapcsolatos problémák jelentését.

A problémákat azonnal jelentse az upstream felé.
Amennyiben lehetséges, alkalmazzon upstream javításokat.
Tegyen hozzá megjegyzéseket a PKGBUILD szkripthez, amelyek tartalmazzák a vonatkozó (upstream) hibakövető jegyekre mutató linkeket. (Ez különösen fontos, mert így más szoftvercsomag-készítők is megérthetik a változtatásokat, és dolgozhatnak a szoftvercsomaggal).

Javasolt az upstream követése olyan segédprogramokkal, mint az nvchecker, nvrs^AUR vagy urlwatch annak érdekében, hogy Ön értesüljön az új stabil kiadásokról.

Könyvtárak

A beállításfájlokat az /etc könyvtárba kell elhelyezni. Ha egynél több beállításfájl létezik, akkor alkönyvtárat szokás használni annak érdekében, hogy a /etc terület a lehető legtisztább maradjon. Használja az /etc/pkg könyvtárat, ahol a pkg a szoftvercsomag neve (vagy egy megfelelő alternatíva, pl. az apache a /etc/httpd/ könyvtárat használja).
A szoftvercsomagfájloknak az alábbi általános könyvtárirányelveket kell követniük:

`/etc`	Rendszer működéséhez elengedhetetlen beállításfájlok
`/usr/bin`	Bináris fájlok
`/usr/lib`	Függvénykönyvtárak
`/usr/include`	Header fájlok
`/usr/lib/pkg`	Modulok, bővítmények stb.
`/usr/share/doc/pkg`	Alkalmazásdokumentáció
`/usr/share/info`	GNU Info rendszerfájlok
`/usr/share/licenses/pkg`	Alkalmazáslicencek
`/usr/share/man`	A man súgók
`/usr/share/pkg`	Alkalmazásadatok
`/var/lib/pkg`	Tartós alkalmazástároló
`/etc/pkg`	A pkg beállításfájljai
`/opt/pkg`	Nagy méretű, önálló szoftvercsomagok

A szoftvercsomagok nem tartalmazhatják a következő könyvtárakat:
- /bin
- /sbin
- /dev
- /home
- /srv
- /media
- /mnt
- /proc
- /root
- /selinux
- /sys
- /tmp
- /var/tmp
- /run

A makepkg feladatai

Amikor a makepkg szoftvercsomag létrehozására van használva, automatikusan a következőket végzi el:

Ellenőrzi, hogy a szoftvercsomag függőségei és makedepends telepítve vannak-e.
Letölti a forrásfájlokat a szerverekről.
Ellenőrzi a forrásfájlok integritását.
Kicsomagolja a forrásfájlokat.
Elvégzi a szükséges foltozásokat.
Lefordítja a forrásból a szoftvert és telepíti egy hamis gyökérkönyvtárba.
Eltávolítja a szimbólumokat a bináris fájlokból.
Eltávolítja a hibakeresési szimbólumokat a könyvtárakból.
Tömöríti a man és/vagy info oldalakat.
Létrehozza a szoftvercsomag-metaadatfájlt, amely minden szoftvercsomag része.
Beletömöríti a fake root könyvtárat (hamis gyökérkönyvtárat) a szoftvercsomagfájlba.
Tárolja a szoftvercsomagfájlt a beállított célkönyvtárban (alapértelmezés szerint az aktuális munkakönyvtárban).

Architektúrák

Ha a forráskódból lefordított szoftvercsomag architektúra-specifikus, akkor az arch tömbnek 'x86_64' értéket kell tartalmaznia. Ellenkező esetben Ön használja az 'any' értéket az architektúrától független szoftvercsomagokhoz.

Licencek

Egy Arch szoftvercsomag esetében kétféle licenc létezik:

PKGBUILD szkriptfájl license mezője

A PKGBUILD szkriptfájl license mezője. Ez a mező a csomagolt szoftver upstream licencét sorolja fel. Ez NEM a szoftvercsomag forrásának a licence. Az ebben a mezőben szereplő licenceknek az [1] SPDX licencformátumot] kell használniuk. További részletekért tekintse meg a PKGBUILD#license című leírást.

Szoftvercsomagok forráskódjainak a licencei

A szoftvercsomagok forráskódjainak a saját licencei. Az RFC40 szerint az Arch Linux előírja, hogy a szoftvercsomagok forráskódjai licencelése a BSD Zero Clause License (0BSD) legyen, míg az RFC52 azt határozza meg, hogy ennek érvényesítésére a REUSE használata szükséges.

Ez lényegében erre vezethető vissza:

Legyen egy LICENSE fájl a forráskódfájlok gyökérkönyvtárában, amely pontosan ennek a tartalomnak felel meg. Ez az Arch Linux 0BSD licence a szoftvercsomagokhoz.
Legyen egy REUSE.toml fájl a forráskódfájlok gyökérkönyvtárában. A pkgctl license setup parancs használható egy megfelelő beállítás legenerálására, amellyel el lehet kezdeni.
Gondoskodjon arról, hogy a pkgctl license check parancs futtatása ne adjon vissza hibát.

Ha Önnek további fájlokat is licencelnie kell, akkor ezekhez a fájlokhoz megfelelő licencet kell választania. Ez általában meglehetősen egyértelmű:

Ha az adott fájlt (például egy indítószkriptet launcher.sh vagy egy systemd szolgáltatásfájlt myunit.service) teljes egészében Ön vagy más Arch munkatárs készítette, akkor 0BSD licenc alá kell helyezni.
Megjegyzés Ha olyan patch-fájlról van szó, amelyet Ön írt, és az upstream-be is be kívánja küldeni, akkor azt továbbra is licencelheti 0BSD-ként az Arch számára, miközben az upstream a saját licencét alkalmazhatja a beküldéskor.
Ha a fájl az upstream-től származik (például egy ikon tool.png vagy egy patch fix.patch), akkor az upstream licencet kell rá alkalmazni.

További részletekért tekintse meg az Arch Linux Dev blogbejegyzést, amely bemutatja a pkgctl-license(1) segédprogram használatát.

Reprodukálható szoftvercsomag-létrehozások

Az Arch azon dolgozik, hogy minden szoftvercsomag reprodukálható legyen. Egy szoftvercsomagot létrehozó személy ellenőrizheti, hogy a szoftvercsomag létrehozása reprodukálható-e. Ezt megteheti a makerepropkg segédprogram használatával, amely a devtools szoftvercsomagban van benne, vagy a repro segédprogram használatával, amely az archlinux-repro szoftvercsomagban van benne.

$ makerepropkg $pkgname-1-1-any.pkg.tar.zst

Vagy:

$ repro -f $pkgname-1-1-any.pkg.tar.zst

Ha a szoftvercsomag létrehozása során (build) szükséges az időbélyeg, akkor használja a SOURCE_DATE_EPOCH környezeti változót. A formátum az upstream-nél van dokumentálva.