Arch package guidelines (Magyar) - ArchWiki

Jump to content

# Arch package guidelines (Magyar)

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

További oldalak az adott témakörben

- /Security (Magyar)
- Arch build system (Magyar)
- Creating packages (Magyar)
- makepkg (Magyar)

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, nvrsAUR 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:

1. Ellenőrzi, hogy a szoftvercsomag függőségei és makedepends telepítve vannak-e.
2. Letölti a forrásfájlokat a szerverekről.
3. Ellenőrzi a forrásfájlok integritását.
4. Kicsomagolja a forrásfájlokat.
5. Elvégzi a szükséges foltozásokat.
6. Lefordítja a forrásból a szoftvert és telepíti egy hamis gyökérkönyvtárba.
7. Eltávolítja a szimbólumokat a bináris fájlokból.
8. Eltávolítja a hibakeresési szimbólumokat a könyvtárakból.
9. Tömöríti a man és/vagy info oldalakat.
10. Létrehozza a szoftvercsomag-metaadatfájlt, amely minden szoftvercsomag része.
11. Beletömöríti a fake root könyvtárat (hamis gyökérkönyvtárat) a szoftvercsomagfájlba.
12. 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:

1. 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.
2. 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.
3. 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.

Category:

- Arch package guidelines (Magyar)

Hidden category:

- Pages or sections flagged with Template:Accuracy

Arch package guidelines (Magyar)
Add topic