Manual-cz

Manuál ke zdrojovým balíčkům XBPS

Tento článek obsahuje vyčerpávající návod, jak vytvořit nové zdrojové balíčky pro XBPS, nativní balíčkovací systém Void Linux .

Obsah

Úvod

Úložiště void-packages obsahuje všechny recepty ke stažení, kompilaci a sestavování binárních balíčků pro Void Linux. Tyto soubory source balíčků se nazývají templates .

Soubory template jsou skripty shellu, které definují variables a functions , které má zpracovat xbps-src , tvůrce balíčků, za účelem generování binárních balíčků. Shell používaný xbps-src je GNU bash; xbps-src si neklade za cíl být kompatibilní s POSIX sh .

Podle konvence všechny šablony začínají komentářem, který říká, že se jedná o template file pro určitý balíček. Většina řádků by měla mít méně než 80 sloupců; proměnné, které vypisují mnoho hodnot, lze rozdělit na nové řádky, přičemž pokračování na dalším řádku je odsazeno o jednu mezeru.

Jednoduchý příklad template je následující:

# Template file for 'foo'
pkgname=foo
version=1.0
revision=1
build_style=gnu-configure
short_desc="Package description, no more than 72 characters"
maintainer="name <email>"
license="GPL-3.0-or-later"
homepage="http://www.foo.org"
distfiles="http://www.foo.org/foo-${version}.tar.gz"
checksum="fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff"

Soubor šablony obsahuje definice ke stažení, sestavení a instalaci souborů balíčků do fake destdir a poté lze vygenerovat binární balíček s definicemi v něm uvedenými.

Nedělejte si starosti, pokud něco není jasné, jak by mělo být. Rezervované variables a functions budou vysvětleny později. Tento soubor template by měl být vytvořen v adresáři, který odpovídá $pkgname , Příklad: void-packages/srcpkgs/foo/template .

Pokud po běhu vše proběhlo v pořádku

$ ./xbps-src pkg <pkgname>

v místním úložišti hostdir/binpkgs bude vygenerován binární balíček s názvem foo-1.0_1.<arch>.xbps

Fáze sestavení balíčku

Sestavení balíčku se skládá z následujících fází:

xbps-src podporuje spuštění pouze zadané fáze, a pokud proběhla úspěšně, fáze bude později přeskočena (pokud její pracovní adresář ${wrksrc} nebude odstraněn pomocí xbps-src clean ).

Konvence pojmenovávání balíčků

Knihovny

Knihovny jsou balíčky, které poskytují sdílené objekty (*.so) v /usr/lib. Měly by být pojmenovány jako jejich název upstream balíčku s následujícími výjimkami:

Příklad: wireshark -> subpkg libwireshark

Knihovny musí být rozděleny do dvou dílčích balíčků: <name> a <name>-devel .

Jazykové moduly

Jazykové moduly jsou rozšířením skriptovacích nebo kompilovaných jazyků. Tyto balíčky samy o sobě neposkytují žádné spustitelné soubory, ale mohou je používat jiné balíčky napsané ve stejném jazyce.

Konvence pojmenování těchto balíčků je:

<language>-<name>

Pokud balíček obsahuje modul i spustitelný soubor, měl by být rozdělen na balíček poskytující spustitelný soubor s názvem <name> a modul s názvem <language>-<name> . Pokud balíček začíná samotným názvem jazyků, lze předponu jazyka vypustit. Krátké názvy jazyků nejsou platnou náhradou jazykové předpony.

Example: perl-URI, python3-pyside2

Jazykové vazby

Jazykové vazby jsou balíčky, které umožňují programům nebo knihovnám mít rozšíření nebo zásuvné moduly napsané v určitém jazyce.

Konvence pojmenování těchto balíčků je:

<name>-<language>

Example: gimp-python3, irssi-perl

Programy

Programy ukládají spustitelné soubory do /usr/bin (nebo ve velmi speciálních případech do jiných .../bin adresářů)

U těchto balíčků by měl být použit název upstream balíčků. Pamatujte, že na rozdíl od mnoha jiných distribucí, void nepíše názvy balíčků malými písmeny. Obecně platí, že pokud tar.gz balíku obsahuje velká písmena, pak by je měl obsahovat i název balíku; pokud tomu tak není, název balíčku je malá písmena.

Programy lze rozdělit na balíčky programů a balíčky knihoven. Programový balíček by měl být pojmenován tak, jak je popsáno výše. Balíček knihovny by měl mít předponu "lib" (viz část Libraries )

Globální funkce

Následující funkce jsou definovány xbps-src a lze je použít na libovolné šabloně:

Zástupné znaky shellu musí být správně uvozovány, Příklad: vmove "usr/lib/*.a" .

Globální proměnné

Následující proměnné jsou definovány xbps-src a lze je použít v jakékoli šabloně:

Dostupné proměnné

Povinné proměnné

Seznam povinných proměnných pro šablonu:

pkgname a version jsou zakázány obsahovat speciální znaky. Proto není nutné je citovat a podle konvence by ani neměly být.

Nepovinné proměnné

Pokud soubor distfile změní svůj kontrolní součet pro každé stažení, protože je zabalen za běhu na serveru, jako např. snapshot tarballs z libovolného z https://*.googlesource.com/ webů, kontrolní součet archive contents lze určit pomocí předřazení reklamy na (@). U tarballů můžete najít kontrolní součet obsahu pomocí příkazu tar xf <tarball.ext> --to-stdout | sha256sum .

Dříve byla k dispozici speciální hodnota noarch , ale od té doby byla odstraněna.

O mnoha typech depends proměnných

Doposud jsme uvedli čtyři typy depends proměnných: hostmakedepends , makedepends , checkdepends a depends . Tyto různé druhy proměnných jsou nezbytné, protože xbps-src podporuje křížovou kompilaci a aby se zabránilo instalaci zbytečných balíčků v prostředí sestavení.

Během procesu sestavení musí být na hostiteli spuštěny programy, jako je yacc nebo kompilátor C. Balíčky obsahující tyto programy by měly být uvedeny v hostmakedepends a budou nainstalovány na hostitele při sestavování cílového balíčku. Některé z těchto balíčků jsou závislé na balíčku base-chroot a nemusí být uvedeny. Je možné, že některé programy potřebné k sestavení projektu jsou umístěny v balíčcích -devel .

Cílový balíček může také záviset na jiných balíčcích pro knihovny, které se mají odkazovat na soubory záhlaví nebo na soubory záhlaví. Tyto balíčky by měly být uvedeny v makedepends a budou odpovídat cílové architektuře bez ohledu na architekturu sestavovacího stroje. Typicky budou makedepends obsahovat hlavně balíčky -devel .

Kromě toho, pokud je nastaveno XBPS_CHECK_PKGS nebo je předána volba -Q do xbps-src , může cílový balíček vyžadovat specifické závislosti nebo knihovny, které jsou propojeny s jeho testovacími binárními soubory, aby mohl spustit testovací sadu. Tyto závislosti by měly být uvedeny v checkdepends a budou nainstalovány, jako by byly součástí hostmakedepends . Některé závislosti, které lze zahrnout do checkdepends , jsou:

A konečně, balíček může vyžadovat určité závislosti za běhu, bez kterých je nepoužitelný. Tyto závislosti, pokud je XBPS nezjistí automaticky, by měly být uvedeny v depends .

Knihovny propojené objekty ELF jsou detekovány automaticky pomocí xbps-src , proto je nelze specifikovat v šablonách pomocí depends . Tato proměnná by měla obsahovat:

Závislosti běhu pro objekty ELF se zjišťují kontrolou, které SONAME vyžadují, a poté jsou SONAME mapovány na binární název balíčku s minimální požadovanou verzí. Soubor common/shlibs nastavuje mapování <SONAME> <pkgname>>=<version> .

Například balíček foo-1.0_1 poskytuje libfoo.so.1 SONAME a software vyžadující tuto knihovnu bude odkazovat na libfoo.so.1 ; výsledný binární balíček bude mít závislost běhu na balíčku foo>=1.0_1 jak je uvedeno v common/shlibs :

# common/shlibs
...
libfoo.so.1 foo-1.0_1
...

Závislosti deklarované přes depends se neinstalují do hlavního adresáře, spíše se kontrolují, pokud existují jako binární balíčky, a jsou automaticky sestaveny xbps-src pokud zadaná verze není v lokálním úložišti.

Ve speciálním případě mohou být virtual závislosti specifikovány jako runtime závislosti v proměnné šablony depends . Několik různých balíčků může poskytovat běžnou funkcionalitu deklarováním virtuálního názvu a verze v proměnné šablony provides (např provides="vpkg-0.1_1" ). Balíčky, které se spoléhají na společnou funkčnost bez ohledu na konkrétního poskytovatele, mohou deklarovat závislost na názvu virtuálního balíčku s předponou virtual? (např. depends="virtual?vpkg-0.1_1" ). Když je balíček sestaven pomocí xbps-src , bude potvrzena existence poskytovatelů virtuálních balíčků a budou sestaveni v případě potřeby. Mapa z virtuálních balíčků na jejich výchozí poskytovatele je definována v etc/defaults.virtual . Jednotlivá mapování mohou být přepsána místními preferencemi v etc/virtual . Komentáře v etc/defaults.virtual poskytují více informací o této mapě.

A konečně, obecně platí, že pokud je balíček sestavován přesně stejným způsobem bez ohledu na to, zda je konkrétní balíček přítomen v makedepends nebo hostmakedepends , neměl by být tento balíček přidán jako závislost na čase sestavení.

Úložiště

Repozitáře definované větví

Globální úložiště převezme název aktuální větve, kromě případů, kdy je název větve hlavní. Potom bude výsledné úložiště v globálním rozsahu. Scénář použití je takový, že uživatel může aktualizovat více balíčků v druhé větvi, aniž by znečišťoval své místní úložiště.

Repozitáře definované balíčkem

Druhým způsobem, jak definovat úložiště, je nastavení proměnné repository v šabloně. Tímto způsobem může správce definovat úložiště pro konkrétní balíček nebo skupinu balíčků. To se v současnosti používá k rozlišení mezi určitými třídami balíčků.

Následující názvy úložišť jsou platné:

Kontrola nových upstream vydání

Nové upstream verze mohou být automaticky kontrolovány pomocí ./xbps-src update-check <pkgname> . V některých případech je potřeba přepsat rozumné výchozí hodnoty přiřazením následujících proměnných v update souboru ve stejném adresáři jako příslušný soubor template :

Manipulace s náplastmi

Někdy je potřeba software opravit, nejčastěji k opravě nalezených chyb nebo k opravě kompilace s novým softwarem.

Pro řešení tohoto problému má xbps-src funkci záplatování. Vyhledá všechny soubory, které odpovídají globu srcpkgs/$pkgname/patches/*.{diff,patch} a automaticky použije všechny soubory, které najde pomocí patch(1) s -Np1 . To se děje během fáze do_patch() . Proměnná PATCHESDIR je k dispozici v šabloně a ukazuje na adresář patches .

Chování záplatování lze změnit následujícími způsoby:

vytvářet stylové skripty

Proměnná build_style určuje metodu sestavení pro sestavení a instalaci balíčku. Očekává název libovolného dostupného skriptu v adresáři void-packages/common/build-style . Vezměte prosím na vědomí, že požadované balíčky pro spuštění skriptu build_style musí být definovány pomocí $hostmakedepends .

Aktuální seznam dostupných skriptů build_style je následující:

U balíčků, které používají metodu sestavení modulu Python ( setup.py nebo PEP 517 ), si můžete vybrat jednu z následujících možností:

Proměnné prostředí pro konkrétní build_style lze deklarovat v názvu souboru, který odpovídá názvu build_style , Příklad:

`common/environment/build-style/gnu-configure.sh`

vytvářet pomocné skripty

Proměnná build_helper specifikuje úryvky shellu, které mají být získávány a které vytvoří vhodné prostředí pro práci s určitými sadami balíčků.

Aktuální seznam dostupných skriptů build_helper je následující:

Funkce

Následující funkce mohou být definovány pro změnu chování, jak se balíček stahuje, kompiluje a instaluje.

Funkce definovaná v šabloně má přednost před stejnou funkcí definovanou skriptem build_style .

Aktuální pracovní adresář pro funkce je nastaven takto:

Možnosti sestavení

Některé balíčky mohou být sestaveny s různými možnostmi sestavení, aby bylo možné povolit/zakázat další funkce; Kolekce zdrojových balíčků XBPS vám to umožňuje pomocí několika jednoduchých úprav souboru template .

Následující proměnné mohou být nastaveny tak, aby umožňovaly možnosti sestavení balíčku:

Po definování těchto požadovaných proměnných můžete zkontrolovat proměnnou build_option_<option> , abyste věděli, zda byla nastavena, a podle toho upravit zdrojový balíček. Kromě toho jsou k dispozici následující funkce:

Následující příklad ukazuje, jak změnit zdrojový balíček, který používá konfiguraci GNU, aby povolil novou možnost sestavení pro podporu obrázků PNG:

# Template file for 'foo'
pkgname=foo
version=1.0
revision=1
build_style=gnu-configure
configure_args="... $(vopt_with png)"
makedepends="... $(vopt_if png libpng-devel)"
...

# Package build options
build_options="png"
desc_option_png="Enable support for PNG images"

# To build the package by default with the `png` option:
#
# build_options_default="png"

...

Podporované možnosti sestavení pro zdrojový balíček lze zobrazit pomocí xbps-src :

$ ./xbps-src show-options foo

Možnosti sestavení lze povolit pomocí parametru -o xbps-src :

$ ./xbps-src -o option,option1 <cmd> foo

Možnosti sestavení lze zakázat jejich přidáním předponu ~ :

$ ./xbps-src -o ~option,~option1 <cmd> foo

Oba způsoby lze použít společně k povolení a/nebo zakázání více možností současně s xbps-src :

$ ./xbps-src -o option,~option1,~option2 <cmd> foo

Možnosti sestavení lze také zobrazit pro binární balíčky pomocí xbps-query(8) :

$ xbps-query -R --property=build-options foo

Trvalé globální možnosti sestavení balíčku lze nastavit pomocí proměnné XBPS_PKG_OPTIONS v konfiguračním souboru etc/conf . Možnosti sestavení pro jednotlivé balíčky lze nastavit pomocí XBPS_PKG_OPTIONS_<pkgname> .

POZNÁMKA: Pokud pkgname obsahuje dashes , měly by být nahrazeny underscores Příklad: XBPS_PKG_OPTIONS_xorg_server=opt .

Seznam podporovaných voleb sestavení balíčku a jeho popis je definován v souboru common/options.description .

INSTALOVAT a ODEBRAT soubory

Útržky shellu INSTALL a REMOVE lze použít k provedení určitých akcí v určené fázi, když je binární balíček instalován, aktualizován nebo odstraněn. Existují některé proměnné, které jsou vždy nastaveny xbps při provádění skriptů:

Příklad toho, jak má být vytvořen skript INSTALL nebo REMOVE , je uveden níže:

# INSTALL
case "$ACTION" in
pre)
    # Actions to execute before the package files are unpacked.
    ...
    ;;
post)
    if [ "$UPDATE" = "yes" ]; then
        # actions to execute if package is being updated.
        ...
    else
        # actions to execute if package is being installed.
        ...
    fi
    ;;
esac

dílčí balíčky mohou mít také své vlastní soubory INSTALL a REMOVE , jednoduše je vytvořte jako srcpkgs/<pkgname>/<subpkg>.INSTALL nebo srcpkgs/<pkgname>/<subpkg>.REMOVE .

POZNÁMKA: Vždy používejte cesty relativně k aktuálnímu pracovnímu adresáři, jinak pokud skripty nelze spustit přes chroot(2) nebudou správně fungovat.

POZNÁMKA: K tisku zpráv nepoužívejte skripty INSTALL/REMOVE, další informace naleznete v další části.

INSTALL.msg a REMOVE.msg soubory

Soubory INSTALL.msg a REMOVE.msg lze použít k vytištění zprávy v době po instalaci nebo před odstraněním.

V ideálním případě by tyto soubory neměly přesáhnout 80 znaků na řádek.

dílčí balíčky mohou mít také své vlastní soubory INSTALL.msg a REMOVE.msg , jednoduše je vytvořte jako srcpkgs/<pkgname>/<subpkg>.INSTALL.msg nebo srcpkgs/<pkgname>/<subpkg>.REMOVE.msg .

Toto by se mělo používat pouze pro kritické zprávy, jako je varování uživatelů o porušení změn.

Vytváření systémových účtů/skupin za běhu

Existuje spouštěč spolu s některými proměnnými, které jsou specificky určeny k vytvoření systémových uživatelů a skupin při konfiguraci binárního balíčku. K tomuto účelu lze použít následující proměnné:

Systémový uživatel je vytvořen pomocí dynamicky přiděleného uid/gid ve vašem systému a je vytvořen jako system account , pokud není nastaveno uid . Pro zadaný system account bude vytvořena nová skupina a bude použita výhradně pro tento účel.

Systémové účty a skupiny musí mít předponu podtržítka, aby se předešlo střetu s názvy uživatelských účtů.

POZNÁMKA: Zásady podtržení se nevztahují na staré balíčky, kvůli nevyhnutelnému porušení změny uživatelského jména by se podle něj měly řídit pouze nové balíčky.

Psaní runitových služeb

Void Linux používá runit pro bootování a dohled nad službami.

Většinu informací o tom, jak je napsat, najdete v jejich FAQ . Následují pokyny specifické pro Void Linux, jak psát služby.

Pokud démon služby podporuje příznaky CLI, zvažte přidání podpory pro jeho změnu prostřednictvím proměnné OPTS čtením souboru s názvem conf ve stejném adresáři jako démon.

#!/bin/sh
[ -r conf ] && . ./conf
exec daemon ${OPTS:- --flag-enabled-by-default}

Pokud služba vyžaduje vytvoření adresáře pod /run nebo jeho odkazu /var/run pro ukládání runtime informací (jako Pidfiles), zapište jej do souboru služby. Pokud jej potřebujete vytvořit se specifickými oprávněními, doporučujeme použít install namísto mkdir -p .

#!/bin/sh
install -d -m0700 /run/foo
exec foo
#!/bin/sh
install -d -m0700 -o bar -g bar /run/bar
exec bar

Pokud služba vyžaduje adresáře v částech systému, které obecně nejsou v dočasných souborových systémech. Poté použijte proměnnou make_dirs v šabloně k vytvoření těchto adresářů, když je balíček nainstalován.

Pokud balíček nainstaluje servisní soubor systemd nebo jinou jednotku, ponechte jej na místě jako referenční bod, pokud jeho zahrnutí nemá žádné negativní vedlejší účinky.

Příklady, kdy neinstalovat systémové jednotky:

  1. Když tak učiníte, změní se běhové chování přibaleného softwaru.
  2. Když se to provádí pomocí příznaku doby kompilace, který také mění závislosti sestavení.

32bitové balíčky

32bitové balíčky se sestavují automaticky, když je tvůrce x86 (32bit), ale existují některé proměnné, které mohou chování změnit:

Dílčí balíčky

Ve výše uvedeném příkladu se vygeneruje pouze binární balíček, ale pomocí některých jednoduchých vylepšení lze z jedné šablony/sestavení vygenerovat více binárních balíčků, tomu se říká subpackages .

Chcete-li vytvořit další subpackages musí template definovat novou funkci s tímto názvem: <subpkgname>_package() , Příklad:

# Template file for 'foo'
pkgname=foo
version=1.0
revision=1
build_style=gnu-configure
short_desc="A short description max 72 chars"
maintainer="name <email>"
license="GPL-3.0-or-later"
homepage="http://www.foo.org"
distfiles="http://www.foo.org/foo-${version}.tar.gz"
checksum="fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff"

# foo-devel is a subpkg
foo-devel_package() {
    short_desc+=" - development files"
    depends="${sourcepkg}>=${version}_${revision}"
    pkg_install() {
        vmove usr/include
        vmove "usr/lib/*.a"
        vmove "usr/lib/*.so"
        vmove usr/lib/pkgconfig
    }
}

Všechny dílčí balíčky potřebují další symbolický odkaz na main balíček, jinak závislosti vyžadující tyto balíčky nenajdou svou template Příklad:

 /srcpkgs
  |- foo <- directory (main pkg)
  |  |- template
  |- foo-devel <- symlink to `foo`

Hlavní balíček by měl specifikovat všechny požadované build dependencies , aby bylo možné sestavit všechny dílčí balíčky definované v šabloně.

Důležitým bodem subpackages je, že jsou zpracovány poté, co hlavní balíček dokončil svou fázi install . Funkce pkg_install() na nich specifikovaná se běžně používá k přesunu souborů z main balíčku destdir do subpackage destdir.

Pomocné funkce vinstall , vmkdir , vcopy a vmove jsou jen obaly, které zjednodušují proces vytváření, kopírování a přesouvání souborů/adresářů mezi main balíčkem destdir ( $DESTDIR ) do subpackage destdir ( $PKGDESTDIR ).

Dílčí balíčky jsou zpracovávány vždy v abecedním pořadí; Chcete-li vynutit vlastní objednávku, lze proměnnou subpackages deklarovat s požadovanou objednávkou.

Některé třídy balíčků

Vývojové balíčky

Vývojový balíček, běžně generovaný jako dílčí balíček, bude obsahovat pouze soubory potřebné pro vývoj, to znamená záhlaví, statické knihovny, symbolické odkazy sdílených knihoven, soubory pkg-config, dokumentaci API nebo jakýkoli jiný skript, který je užitečný pouze při vývoji pro cíl. software.

Vývojový balíček by měl záviset na balíčcích, které se vyžadují k propojení s poskytnutými sdílenými knihovnami, tj. pokud libfoo poskytuje sdílenou knihovnu libfoo.so.2 a propojení potřebuje -lbar , balíček poskytující sdílenou knihovnu libbar by měl být přidán jako závislost ; a s největší pravděpodobností bude záviset na jeho vývojovém balíčku.

Pokud vývojový balíček poskytuje soubor pkg-config , měli byste ověřit, jaké závislosti potřebuje balíček pro dynamické nebo statické propojení, a přidat příslušné development balíčky jako závislosti.

Vývojové balíčky pro jazyky C a C++ obvykle vmove následující podmnožinu souborů z hlavního balíčku:

Datové balíčky

Dalším běžným typem dílčího balíčku je dílčí balíček -data . Tento typ dílčího balíku se používá k rozdělení na architektuře nezávislé, velké (ger) nebo velké množství dat z hlavní části balíku a části závislé na architektuře. Je na vás, abyste se rozhodli, zda má podbalíček -data pro váš balíček smysl. Tento typ je běžný pro hry (grafika, zvuk a hudba), knihovny součástí (CAD) nebo materiál karet (mapy). Hlavní balíček pak musí mít depends="${pkgname}-data-${version}_${revision}" , možná kromě jiných, neautomatických závislostí.

Balíčky dokumentace

Balíčky určené pro interakci uživatele ne vždy bezpodmínečně vyžadují svou dokumentační část. Uživatel, který nechce např. vyvíjet s Qt5, nebude muset instalovat (obrovský) balíček qt5-doc. Odborník to nemusí potřebovat nebo se rozhodne používat online verzi.

Obecně je balíček -doc užitečný, pokud lze hlavní balíček použít s dokumentací i bez dokumentace a velikost dokumentace není opravdu malá. Základní balíček a podbalíček -devel by měly být malé, aby při sestavování balíčků závislých na konkrétním balíčku nebylo nutné bezdůvodně instalovat velké množství dokumentace. Velikost části dokumentace by tedy měla být vaším vodítkem při rozhodování, zda oddělit podbalíček -doc či nikoli.

Python balíčky

Balíčky Pythonu by měly být sestaveny se stylem sestavení python3-module , pokud je to možné. Tím se nastaví některé proměnné prostředí potřebné k umožnění křížové kompilace. Je také možná podpora umožňující sestavení modulu python pro více verzí z jedné šablony. Styl sestavení python3-pep517 poskytuje prostředky k sestavení pythonových balíčků, které poskytují definici sestavovacího systému v souladu s PEP 517 bez tradičního skriptu setup.py . Styl sestavení python3-pep517 neposkytuje konkrétní backend sestavení, takže balíčky budou muset přidat vhodného poskytovatele backendu do hostmakedepends .

Balíčky Pythonu, které se spoléhají na python3-setuptools by obecně měly mapovat závislosti setup_requires v setup.py na hostmakedepends v šabloně a install_requires závislosti na depends v šabloně; include python3 in depends , pokud neexistují žádné další závislosti na pythonu. Pokud balíček obsahuje zkompilované rozšíření, měly by být balíčky python3-devel přidány do makedepends , stejně jako všechny balíčky python, které také poskytují nativní knihovny, se kterými bude rozšíření propojeno (i když je tento balíček také zahrnut v hostmakedepends , aby vyhovoval setuptools ) .

Poznámka : Python setuptools se pokusí použít pip nebo EasyInstall k načtení chybějících závislostí v době sestavování. Pokud si po sestavení balíčku všimnete varování o ukončení podpory EasyInstall nebo vejcích python přítomných v ${wrksrc}/.eggs , pak by tyto balíčky měly být přidány do hostmakedepends .

Následující proměnné mohou ovlivnit, jak jsou balíčky python sestavovány a konfigurovány v době po instalaci:

V šablonách je také definována sada užitečných proměnných:

Proměnná Hodnota
py2_ver 2.X
py2_lib usr/lib/python2.X
py2_sitelib usr/lib/python2.X/site-packages
py2_inc usr/include/python2.X
py3_ver 3.X
py3_lib usr/lib/python3.X
py3_sitelib usr/lib/python3.X/site-packages
py3_inc usr/include/python3.Xm

POZNÁMKA: Očekává se, že musí být vygenerovány další subpkg, aby bylo možné sbalit více verzí pythonu.

Přejít na balíčky

Pokud je to možné, balíčky Go by měly být sestaveny stylem go build. Styl sestavení go se stará o stahování závislostí Go a nastavení křížové kompilace.

Následující proměnné šablony ovlivňují způsob, jakým jsou sestavovány balíčky Go:

Následující proměnné prostředí ovlivňují, jak jsou balíčky Go sestaveny:

Občas je nutné provádět operace ze stromu zdroje Go. To obvykle potřebují programy používající go-bindata nebo jinak připravující některá aktiva. Pokud je to možné, proveďte to v pre_build(). Cesta ke zdroji balíčku uvnitř $GOPATH je dostupná jako $GOSRCPATH .

Haskell balíčky

Haskell balíčky lze sestavit buď stylem cabal , nebo haskell-stack . Použijte ten, který je pohodlnější nebo lépe podporovaný upstreamem. Někdy je možný pouze jeden z těchto dvou. U balíčků, které obsahují haskellové části, ale používají jiný styl sestavení, jako je gnu-makefile , nezapomeňte použít haskell build helper.

Následující proměnné ovlivňují, jak jsou balíčky sestavovány pomocí cabal:

A tyto proměnné ovlivňují, jak jsou balíčky sestavovány pomocí stack:

Pro opravu závislostí balíčků Haskell je nutné je explicitně načíst z Hackage přidáním do distfiles místo aby je stahoval Cabal nebo Stack. Po extrahování a opravě lze cestu k opravené verzi přidat k packages v souboru cabal.project nebo stack.yaml . Stack je automaticky vyhledá, pokud soubor stack.yaml neexistuje, prohledáním adresáře. Nástroj pro sestavení pak použije opravenou verzi závislosti, místo aby ji stahoval z Hackage.

Balíčky písem

Balíčky písem se píší velmi jednoduše, vždy se nastavují pomocí následujících proměnných:

Přejmenování balíčku

Odebírání balíčku

Následuje seznam věcí, které je třeba udělat, aby bylo zaručeno, že odstranění šablony balíčků a potažmo jeho binárních balíčků z repozitářů Void Linuxu proběhne hladce.

Před odstraněním šablony balíčku:

Při odstraňování šablony balíčku:

Spouštěče XBPS

Spouštěče XBPS jsou sbírkou úryvků kódu poskytovaných balíčkem xbps-triggers , které se přidávají do skriptů INSTALL/REMOVE balíčků buď ručně nastavením proměnné triggers v šabloně, nebo automaticky, když jsou splněny specifické podmínky.

Následuje seznam všech dostupných spouštěčů, jejich aktuální stav, co každý z nich dělá a jaké podmínky musí splňovat, aby byl automaticky zahrnut do balíčku.

Toto není úplný přehled balíčku. Doporučuje se přečíst odkazované proměnné a samotné spouštěče.

appstream-cache

Spouštěč appstream-cache je zodpovědný za opětovné sestavení mezipaměti metadat appstreamu.

Během instalace spustí appstreamcli refresh-cache --verbose --force --datapath $APPSTREAM_PATHS --cachepath var/cache/app-info/gv . Ve výchozím nastavení jsou APPSTREAM_PATHS všechny cesty, které bude appstreamcli hledat pro soubory metadat.

Adresáře prohledávané appstreamcli jsou:

Během odstraňování balíčku AppStream dojde k odstranění adresáře var/cache/app-info/gv .

Automaticky se přidá do balíčků, které mají soubory XML v jednom z adresářů prohledaných appstreamcli.

binfmts

Spouštěč binfmts je zodpovědný za registraci a odstranění libovolných spustitelných binárních formátů, známých jako binfmts.

Během instalace/odstranění používá update-binfmts z balíčku binfmt-support k registraci/odstranění položek z libovolné databáze spustitelných binárních formátů.

Je automaticky přidán do balíčků, které obsahují soubory v usr/share/binfmts . Tyto soubory by měly být ve formátu update-binfmts a budou importovány pomocí update-binfmts --import .

I když to není preferováno, spouštěč lze přidat také pomocí proměnné binfmts , která by měla obsahovat řádky definující binfmts pro registraci:

/path/to/interpreter [update-binfmts binary format specification arguments ...]
...

Viz update-binfmts(8) pro více podrobností.

dkms

Spouštěč dkms je zodpovědný za kompilaci a odstranění dynamických modulů jádra balíčku.

Během instalace trigger zkompiluje a nainstaluje dynamický modul pro všechny linux balíčky, které mají nainstalovaný odpovídající balíček linux-headers. Během odebírání bude odebrán odpovídající modul

Chcete-li zahrnout spouštěč, použijte proměnnou dkms_modules , protože spouštěč nedělá nic, pokud není definován.

schémata gconf

Spouštěč gconf-schemas je zodpovědný za registraci a odstranění souborů .schemas a .entries do adresáře databáze schémat.

Během instalace používá gconftool-2 k instalaci souborů .schemas a .entries do usr/share/gconf/schemas . Během odstraňování používá gconftool-2 k odstranění položek a schémat patřících k balíčku, který je odstraňován z databáze.

Chcete-li jej zahrnout, přidejte do triggers gconf-schemas a přidejte vhodná .schemas do proměnné gconf_schemas a .entries do gconf_entries .

Automaticky se přidává do balíčků, které mají jako adresář /usr/share/gconf/schemas . Všechny soubory s příponou schématu v tomto adresáři jsou předány spouštěči.

gdk-pixbuf-loadery

Spouštěč gdk-pixbuf-loaders je zodpovědný za udržování mezipaměti zavaděčů GDK Pixbuf.

Během instalace spouští gdk-pixbuf-query-loaders --update-cache a také smaže zastaralý soubor etc/gtk-2.0/gdk-pixbuf.loaders pokud existuje. Během odstraňování balíčku gdk-pixbuf odstraní soubor mezipaměti, pokud je přítomen. Normálně na usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache .

Lze jej přidat definováním gdk-pixbuf-loaders v proměnné triggers . Je také automaticky přidán do každého balíčku, který má jako adresář k dispozici cestu usr/lib/gdk-pixbuf-2.0/2.10.0/loaders .

gio-moduly

Spouštěč gio-modules je zodpovědný za aktualizaci mezipaměti modulu Glib GIO moduly gio-querymodules z balíčku glib

Během instalace a odebrání pouze spustí gio-querymodules , aby aktualizoval soubor mezipaměti přítomný pod usr/lib/gio/modules .

Automaticky se přidává do balíčků, které mají jako adresář /usr/lib/gio/modules .

gsettings-schémata

Spouštěč gsettings-schemas je zodpovědný za kompilaci souborů schématu Glib Glib GSettings XML během instalace a odstranění zkompilovaných souborů během odstraňování.

Během instalace používá glib-compile-schemas z glib ke kompilaci schémat do souborů s příponou .compiled do /usr/share/glib-2.0/schemas .

Během odstraňování balíčku glib smaže všechny soubory v /usr/share/glib-2.0/schemas , které končí příponou .compiled.

Je automaticky přidán do balíčků, které mají jako adresář /usr/share/glib-2.0/schemas .

gtk-ikona-mezipaměť

Spouštěč gtk-icon-cache je zodpovědný za aktualizaci mezipaměti ikon gtk+.

Během instalace používá gtk-update-icon-cache k aktualizaci mezipaměti ikon.

Při odstraňování balíčku gtk+ smaže soubor icon-theme.cache v adresářích definovaných proměnnou gtk_iconcache_dirs .

Automaticky se přidává do balíčků, které mají jako adresář k dispozici /usr/share/icons , všechny adresáře v tomto adresáři mají svou absolutní cestu předán spouštěči.

gtk-immodules

Spouštěč gtk-immodules je zodpovědný za aktualizaci souboru modulů IM (Input Method) pro gtk+.

Během instalace používá gtk-query-immodules-2.0 --update-cache k aktualizaci souboru mezipaměti. Odstraní také zastaralý konfigurační soubor etc/gtk-2.0/gtk.immodules pokud existuje.

Během odstraňování balíčku gtk+ odstraní soubor mezipaměti, který se nachází na usr/lib/gtk-2.0/2.10.0/immodules.cache .

Automaticky se přidává do balíčků, které mají jako adresář /usr/lib/gtk-2.0/2.10.0/immodules .

gtk-pixbuf-loadery

gtk-pixbuf-loaders je starý název pro aktuální spouštěč gdk-pixbuf-loaders a je v procesu odstraňování. V současné době se znovu spouští do gdk-pixbuf-loaders jako opatření kompatibility.

Informace o tom, jak to funguje, najdete v gdk-pixbuf-loaders .

gtk3-immodules

Spouštěč gtk3-immodules je zodpovědný za aktualizaci souboru modulů IM (Input Method) pro gtk+3.

Během instalace spustí gtk-query-immodules-3.0 --update-cache pro aktualizaci souboru mezipaměti. Také odstraní zastaralý konfigurační soubor etc/gtk-3.0/gtk.immodules pokud existuje.

Během odstraňování balíčku gtk+3 odstraní soubor mezipaměti, který se nachází na usr/lib/gtk-3.0/3.0.0/immodules.cache .

Automaticky se přidává do balíčků, které mají jako adresář /usr/lib/gtk-3.0/3.0.0/immodules .

hwdb.d-dir

Spouštěč hwdb.d-dir je zodpovědný za aktualizaci hardwarové databáze.

Během instalace a odebrání spouští usr/bin/udevadm hwdb --root=. --update .

Je automaticky přidán do balíčků, které mají jako adresář /usr/lib/udev/hwdb.d .

info-soubory

Spouštěč info-files je zodpovědný za registraci a odregistrování GNU informačních souborů balíčku.

Kontroluje existenci informačních souborů, které jsou mu předkládány, a zda běží pod jinou architekturou.

Během instalace používá install-info k registraci informačních souborů do usr/share/info .

Během odstraňování používá install-info --delete k odstranění informačních souborů z registru umístěného na usr/share/info .

Pokud běží pod jinou architekturou, pokusí se použít utilitu install-info hostitele.

initramfs-regenerate

Spouštěč initramfs-regenerate spustí regeneraci všech obrazů initramfs jádra po instalaci nebo odstranění balíčku. O spoušť je třeba požádat ručně.

Tento háček je pravděpodobně nejužitečnější pro balíčky DKMS, protože poskytuje prostředek pro zahrnutí nově zkompilovaných modulů jádra do obrazů initramfs pro všechna aktuálně dostupná jádra. Při použití v balíčku DKMS se doporučuje ručně zahrnout spouštěč dkms před spouštěč initramfs-regenerate pomocí např.

triggers="dkms initramfs-regenerate"

Ačkoli xbps-src automaticky zahrne spouštěč dkms kdykoli je nainstalován dkms_modules , automatické přidání přijde po initramfs-regenerate , což způsobí, že obrazy initramfs budou znovu vytvořeny před kompilací modulů.

Ve výchozím nastavení spouštěč používá dracut --regenerate-all k opětovnému vytvoření obrázků initramfs. Pokud /etc/default/initramfs-regenerate existuje a definuje INITRAMFS_GENERATOR=mkinitcpio , spouštěč místo toho použije mkinitcpio a zacyklí všechny verze jádra, pro které se zdá, že jsou nainstalovány moduly. Případně nastavení INITRAMFS_GENERATOR=none zcela zakáže regeneraci obrazu.

kernel-háky

Spouštěč kernel-hooks je zodpovědný za spouštění skriptů během instalace/odebírání balíčků jádra.

Dostupné cíle jsou před instalací, před odstraněním, po instalaci a po odstranění.

Při spuštění se pokusí spustit všechny spustitelné soubory nalezené pod etc/kernel.d/$TARGET . Proměnná TARGET je jedním ze 4 cílů dostupných pro spouštěč. Vytvoří také adresář, pokud není přítomen.

Během aktualizací se nebude pokoušet spustit žádné spustitelné soubory, když běží s cílem před odstraněním.

Je přidána automaticky, pokud je definována pomocná proměnná kernel_hooks_version . Není však povinné jej mít definované.

mimedb

Spouštěč mimedb je zodpovědný za aktualizaci databáze shared-mime-info.

Ve všech spuštěních se pouze spustí update-mime-database -n usr/share/mime .

Je automaticky přidán do balíčků, které mají jako adresář k dispozici /usr/share/mime .

mkdirs

Spouštěč mkdirs je zodpovědný za vytváření a odstraňování adresářů diktovaných proměnnou make_dirs .

Během instalace vezme proměnnou make_dirs a rozdělí ji do skupin po 4 proměnných.

Bude pokračovat v rozdělování hodnot make_dirs do skupin po 4, dokud hodnoty neskončí.

Během instalace vytvoří adresář s dir a poté nastaví režim s mode a oprávněním pomocí uid:gid .

Během odstraňování smaže adresář pomocí rmdir .

Chcete-li zahrnout tento spouštěč, použijte proměnnou make_dirs , protože spouštěč nedělá nic, pokud není definován.

pango-moduly

Spouštěč pango-modules se aktuálně odstraňuje, protože upstream odstranil kód, který je za něj zodpovědný.

Slouží k aktualizaci souboru pango modules pomocí pango-modulesquery během instalace libovolného balíčku.

V současné době odstraňuje soubor etc/pango/pango.modules během odstraňování balíčku pango.

Může být přidán definováním pango-modules v proměnné triggers a nemá žádný způsob, jak se automaticky přidat do balíčku.

pycompile

Spouštěč pycompile je zodpovědný za kompilaci kódu pythonu do nativního bajtkódu a odstranění generovaného bajtkódu.

Během instalace zkompiluje veškerý kód pythonu pod cestami, které jsou uvedeny v pycompile_dirs a všechny moduly popsané v pycompile_module do nativního bytecode a aktualizuje mezipaměť ldconfig(8).

Během odstraňování odstraní veškerý nativní bytecode a aktualizuje mezipaměť ldconfig(8).

K zahrnutí tohoto spouštěče použijte proměnné pycompile_dirs a pycompile_module . Spouštěč neprovede nic, pokud není definována alespoň jedna z těchto proměnných.

Proměnnou python_version lze nastavit tak, aby řídila chování spouštěče.

registr-shell

Spouštěč registry-shell je zodpovědný za registraci a odstraňování položek shellu do etc/shells .

Během instalace připojí soubor etc/shells s novým shellem a také změní oprávnění k souboru na 644 .

Během odstraňování použije sed k odstranění shellu ze souboru.

Chcete-li zahrnout tento spouštěč, použijte proměnnou register_shell , protože spouštěč nedělá nic, pokud není definován.

systémové účty

Spouštěč systémových účtů je zodpovědný za vytváření a deaktivaci systémových účtů a skupin.

Během odstraňování deaktivuje účet nastavením Shell na /bin/false, Home na /var/empty a připojením '- pro odinstalovaný balíček $pkgname' do Popisu. Příklad: transmission unprivileged user - for uninstalled package transmission

Tento spouštěč lze použít pouze pomocí proměnné system_accounts .

texmf-dist

Spouštěč texmf-dist je zodpovědný za regeneraci texmf databází TeXLive.

Během instalace i odebrání regeneruje databáze texhash i formátování pomocí texhash a fmtutil-sys a přidává nebo odstraňuje jakékoli nové hashe nebo formáty.

Běží na každém balíčku, který změní /usr/share/texmf-dist. To je pravděpodobně přehnané, ale je to mnohem čistší než kontrola každého adresáře formátu a každého adresáře, který je hašován. Navíc je velmi pravděpodobné, že jakýkoli balíček dotýkající se /usr/share/texmf-dist stejně vyžaduje jeden z těchto spouštěčů.

update-desktopdb

Spouštěč update-desktopdb je zodpovědný za aktualizaci systémové databáze MIME.

Během instalace se spustí update-desktop-database usr/share/applications což povede k vytvoření souboru mezipaměti na usr/share/applications/mimeinfo.cache .

Během odebírání balíčku desktop-file-utils se odstraní soubor mezipaměti, který byl vytvořen během instalace.

Je automaticky přidán do balíčků, které mají /usr/share/applications k dispozici jako adresář.

x11-fonty

Spouštěč x11-fonts je zodpovědný za opětovné sestavení souborů fonts.dir a fonts.scale pro balíčky, které instalují fonty X11, a aktualizuje mezipaměť fontconfig pro tyto fonty.

Během instalace a odstranění spouští mkfontdir , mkfontscale a fc-cache pro všechny adresáře písem, které byly zadány přes proměnnou font_dirs .

Chcete-li zahrnout tento spouštěč, použijte proměnnou font_dirs , protože spouštěč nedělá nic, pokud není definován.

xml-katalog

Spouštěč xml-catalog je zodpovědný za registraci a odstraňování položek katalogu SGML/XML.

Během instalace používá xmlcatmgr k registraci všech katalogů, které mu předávají proměnné sgml_entries a xml_entries v usr/share/sgml/catalog a usr/share/xml/catalog .

Během odstraňování používá xmlcatmgr k odstranění všech katalogů, které mu byly předány proměnnými sgml_entries a xml_entries v usr/share/sgml/catalog a usr/share/xml/catalog .

Chcete-li zahrnout tento spouštěč, použijte proměnnou sgml_entries nebo/a proměnnou xml_entries , protože spouštěč nebude dělat nic, pokud nebude žádná z nich definována.

Zrušte konkrétní dokumentaci

Chcete-li zdokumentovat podrobnosti o konfiguraci a použití balíčku specifické pro Void Linux, které nepokrývá upstream dokumentace, vložte poznámky do srcpkgs/<pkgname>/files/README.voidlinux a nainstalujte pomocí vdoc "${FILESDIR}/README.voidlinux" .

Poznámky

Přispívání přes git

Pro začátek si na GitHubu vytvořte fork void-linux repozitáře void-packages a naklonujte ho:

$ git clone git@github.com:<user>/void-packages.git

Viz CONTRIBUTING.md pro informace o tom, jak formátovat vaše odevzdání a další tipy pro přispívání.

Jakmile provedete změny ve vašem forked úložišti, odešlete žádost o stažení githubu.

Chcete-li, aby byl váš rozvětvený repozitář vždy aktuální, nastavte upstream dálkové ovládání tak, aby načítalo nové změny:

$ git remote add upstream https://github.com/void-linux/void-packages.git
$ git pull --rebase upstream master

Pomoc

Pokud po přečtení této manual stále potřebujete nějakou pomoc, připojte se k nám na #xbps přes IRC na irc.libera.chat .