Creació de paquets a Arch Linux (inclòs lAUR)

A Arch Linux, els repositoris oficials són: core, extra i community. Aquests paquets ja estan compilats i s'instal·len mitjançant pacman. En la seva majoria, els usuaris generals poden ignorar que aquests 3 dipòsits oficials estan separats. Core conté els paquets més crítics, com ara el nucli, el procés d'arrencada, les xarxes, la gestió de paquets, openssh, etc. També té requisits més estrictes de proves més exhaustives abans que es publiquin noves versions. Extra conté altres paquets populars que no són tan crítics, com ara un servidor X, gestors de finestres o navegadors web. La comunitat conté paquets menys populars. Només els usuaris de confiança (uns 60 usuaris actius que van ser votats per altres usuaris de confiança) tenen accés per fer canvis als repositoris oficials.

El 2019, hi ha uns 11.000 paquets als dipòsits oficials, a https://www.archlinux.org/packages . Però, hi ha molts altres programes disponibles a Linux. Per tant, l'AUR (Arch Linux User Repository) existeix perquè qualsevol usuari d'Arch pugui afegir un nou programa i convertir-se en el seu mantenedor, o adoptar un paquet "orfe" sense un mantenedor actual. Hi ha uns 55.000 paquets a l'AUR, a https://aur.archlinux.org/ .

Hi ha 3 diferències crítiques amb l'AUR:

1. Un cop més, aquests paquets els pot produir qualsevol usuari, fins i tot un de nou.
2. L'AUR només allotja un PKGBUILD, un script d'intèrpret d'ordres per fer automàticament el paquet, no binaris compilats. (De vegades també conté petits pedaços de text o scripts d'intèrpret d'ordres d'instal·lació/actualització/desinstal·lació). Això ha fet un treball extraordinari permetent a qualsevol usuari contribuir, alhora que mitiguen les possibilitats que algú pugui distribuir codi maliciós. La comunitat Arch encara és molt útil pel que fa als problemes amb els paquets AUR, però cal assenyalar que l'ús d'ells és sota el vostre propi risc. Com que tot el que proporciona és un PKGBUILD, és la vostra responsabilitat revisar un PKGBUILDque fareu servir. (Per descomptat, molts usuaris no ho fan i només confien en altres per vigilar.)
3. Com pacmanque no interactua directament amb l'AUR, és la vostra responsabilitat actualitzar els paquets AUR. Quan actualitzeu periòdicament tot el vostre sistema mitjançant pacman, no baixarà automàticament les actualitzacions dels PKGBUILDfitxers AUR , les compilarà i les instal·larà.

Tot i que aquest article se centra a crear paquets des de l'AUR, es poden utilitzar les mateixes tècniques per crear paquets des dels dipòsits oficials.

PKGBUILD

En comparació amb un .specfitxer que utilitzen moltes altres distribucions, a PKGBUILDés un script d'intèrpret d'ordres curt i senzill. Tot i que alguns paquets són més complexos, simplement poden ser similars als següents:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

Aquest document fa referència a:

• PKGNAME: el nom d'un paquet
• PKGVER: la versió d'un paquet (quasi sempre coincideix amb el número de versió de l'aigua amunt)
• PKGREL: La "versió" d'Arch PKGBUILDper a una versió específica PKGVER(normalment 1, però s'incrementa si cal fer canvis a una versió PKGBUILDentre versions amunt)
• ARCH: Les arquitectures sobre les quals es pot construir el paquet (una mica heretats, ja que els dipòsits oficials d'Arch Linux només admeten "x86_64" (CPU de 64 bits), però els paquets AUR encara poden suportar "i686" (CPU de 32 bits) o "qualsevol" designar l'arquitectura és irrellevant)
• PKGBUILD/ETC: Qualsevol fitxer que hi hagi al repositori AUR; el PKGBUILD, i qualsevol altre pedaç de text petit, o instal·lar/actualitzar/desinstal·lar scripts d'intèrpret d'ordres. No inclou fitxers aigües amunt a la sourcematriu.

Tot i que l'AUR ha demostrat ser extremadament fiable, és una bona idea mirar un PKGBUILD/ETCper assegurar-se que obté la font d'un lloc en el qual esteu disposat a confiar; (per exemple, una ubicació oficial aigües amunt, que pot ser de github, però no només el repositori github d'alguna persona aleatòria que no estigui relacionada amb el paquet aigües amunt); i que PKGBUILD/ETCno conté cap codi sospitós.

Obtenció PKGBUILD/ETC

De l'AUR

Si els repositoris oficials no contenen un paquet que voleu instal·lar, cerqueu-lo a https://aur.archlinux.org/ . Amb sort, trobareu que el que busqueu existeix, està actualitzat i es manté.

La millor manera d'obtenir PKGBUILD/ETCl'AUR és clonar-lo mitjançant git.

Instal·leu git, si encara no ho és:

# pacman -S git

Utilitzeu l'"URL de clonació de Git" que es mostra al lloc web d'AUR per a aquest paquet:

$ git clone https://aur.archlinux.org/fslint.git

Entra al directori i mira el seu contingut. (Tot el que s'indica aquí, excepte . .. .gités el PKGBUILD/ETC):

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

Si examineu PKGBUILD, espereu que vegeu que utilitza el codi font oficial amunt i realitza els passos típics per construir un paquet, de manera que sembla fiable. El .SRCINFOsol conté la informació mostrada a la pàgina web sobre el paquet, pel que no és preocupant. Si hi ha altres fitxers aquí, no són proporcionats (directament) per upstream, de manera que PKGBUILDs'han d'examinar els fitxers i com s'utilitzen a l' , per assegurar-vos que no contenen res sospitós.

Des dels dipòsits oficials

Encara que es requereix molt menys sovint, podeu crear un paquet ja als repositoris oficials, per incloure un nou pedaç, crear una versió més nova, etc.

Obteniu PKGBUILD/ETCdels repositoris bàsics i addicionals:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

Des del repositori de la comunitat:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

Actualització PKGBUILD/ETC

Si PKGBUILD/ETCes publica una actualització , podeu tornar a aquest directori fet amb git clone, i actualitzar-los:

$ git pull

A continuació, recompileu i actualitzeu el paquet amb el mètode que trieu, a continuació.

Compilant

Hi ha moltes maneres de compilar paquets. En definitiva, tot fa servir makepkg. Hi ha 2 maneres oficialment compatibles:

• Per utilitzar directament makepkg, vegeu https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Per utilitzar indirectament makepkgen un clean chroot, vegeu https://www.vultr.com/docs/using-devtools-on-arch-linux .

Hi ha molts programes d'ajuda AUR, (com l' makepkgembolcall), que no tenen suport oficial per Arch, com ara aurutils, yay, i els recentment discontinuats aurmani yaourt. Fins i tot si utilitzeu un d'aquests altres programes d'ajuda, és molt recomanable que us familiaritzeu amb les maneres oficials de ser més efectius quan alguna cosa va malament.

La resta d'aquest document s'utilitzarà YOUR BUILDERper referir- se al mètode que trieu.

Repositori local

Podeu configurar un dipòsit local perquè sigui una ubicació central per a tots els paquets que creeu.

Col·loqueu el repositori local allà on vulgueu:

# mkdir /archLocalRepo

Executeu YOUR BUILDERsense cap opció d'instal·lació automàtica i copieu el paquet al vostre repositori local.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

Afegiu el nou paquet a l'índex del repositori:

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

Per eliminar un paquet de l'índex del repositori i del propi fitxer del paquet:

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

Si necessiteu substituir un fitxer de paquet existent, heu d'eliminar per separat el que s'està substituint i, a continuació, afegir-ne un de nou. No podeu simplement copiar el fitxer nou sobre l'antic.

Configureu pacman-lo per utilitzar el vostre dipòsit local editant /etc/pacman.conf, i afegiu el següent al final:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Necessiteu pacmanactualitzar els seus coneixements sobre bases de dades (inclòs el vostre local), repositoris; per veure els paquets que hi heu afegit:

# pacman -Sy

A continuació, podeu instal·lar el paquet, no de manera diferent que si estigués en un dipòsit oficial:

# pacman -S <PKGNAME>

Note if the package is merely a dependency of another package you are going to install, you don't need to install it directly. When you install this other package, pacman will automatically find and install the dependency packages in your local repository.

Compile Faster

By default, YOUR BUILDER compiles using a single thread. On multi CPU systems, you can allow using multiple threads where possible. The build system will compile parts of the source code in parallel when it can. Sometimes parts of code require other parts it interacts with to already be compiled, so you won't always see as many threads being used as are allowed. Edit /etc/makepkg.conf.

To allow using as many threads as you have virtual cores, add the following:

MAKEFLAGS="-j$(nproc)"

Note: This will run the command nproc every time, so it will always use the current number of cores, in case you upgrade your Vultr server

To allow using multiple virtual cores, but not all of them, such as to reduce impact to overall system performance, add a specific number. For example, if you have 24 cores, you could allow 21 to be used:

MAKEFLAGS="-j21"

Specifying more threads than the number of virtual cores you have will decrease performance.

It's fairly rare, but some packages' build systems have problems with parallel compilation, from not properly defining dependencies between parts of code. Typically, those packages' PKGBUILD files will handle this for you by invoking make -j1, which overrides the default you set. If it needs this and it's missing, report it to the Arch package maintainer.

Error de signatura PGP

Una PKGBUILDmatriu font pot contenir .asco .sigfitxers. Sovint s'inclouen mitjançant l'expansió de bash brace, de manera que es pot perdre fàcilment:

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

Si algun d'aquests formats de fitxers de signatura s'inclou a la matriu d'origen, YOUR BUILDERautomàticament intentarà verificar la signatura de l'arxiu d'origen amunt. La clau PGP de la signatura ha d'estar a l'anell de claus de l'usuari; en cas contrari, avortarà amb l'error:

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

És important entendre que una clau GPG es pot mostrar de diverses maneres. La seva empremta digital és de 40 caràcters hexadecimals i és el que hauríeu d'utilitzar sempre. Una identificació de clau llarga són els darrers 16 dígits, i una identificació de clau curta són els darrers 8 dígits. Tot i que més curt és convenient, permet duplicats, cosa que anul·la tot el raonament darrere de la verificació de signatures. Pitjor encara, se sap que els atacants generen claus falses que coincideixen amb claus de menor longitud per a desenvolupadors d'alt perfil.

Obteniu i verifiqueu l'empremta digital de la clau PGP

Si encara no heu provat de crear el paquet, descarregueu les fonts que inclouran el fitxer de signatura: (Si heu provat de construir, ja hi estarà)

$ makepkg --nobuild --noextract

Per obtenir l'empremta digital completa:

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

Idealment, hauríeu de verificar aquesta empremta digital des de aigües amunt. Per estar segur, aigües amunt hauria de donar les claus dels seus responsables en algun lloc del seu lloc web o a la font. Simplement cercar la clau en un servidor de claus no fa res. Un atacant pot enviar fàcilment una clau falsa, perquè els servidors de claus no verifiquen l'autenticitat. Les claus es poden signar amb altres claus, de manera que si ja teniu una clau en la qual confieu, hauríeu d'estar bastant segur confiant en qualsevol clau que hagin signat.

Això pot ser una mica de feina, sobretot quan aigües amunt no publica la seva empremta digital o la col·loca en un lloc fàcil de trobar. El PKGBUILDcontindrà una validpgpkeysmatriu, que va ser afegit pel mantenidor d'Arch. Si el paquet és un dipòsit oficial, això vol dir que un usuari de confiança el va col·locar allà i hauríeu de ser bastant segur de confiar en qualsevol cosa que s'indiqui a la matriu. Si el paquet està a l'AUR, recordeu que només vol dir que un altre usuari d'Arch el va col·locar allà. Si us preocupa confiar-hi, sempre podeu mirar l'usuari per veure què ha fet en el passat amb Arch.

Afegeix la clau PGP al teu anell de claus

Per afegir l'empremta digital al teu clauer:

$ gpg --recv-keys <FINGERPRINT>

Ara podeu executar YOUR BUILDER, i confiarà en l'empremta digital.

Paquets de desenvolupament AUR

Els paquets AUR amb noms que acaben -git, -svn, -bzro -hgsón versions de desenvolupament, que utilitzen l'última confirmació del sistema de control de versions de upstream en lloc de la darrera versió de upstream. Per exemple, a-gitEl paquet utilitzaria l'últim commit de la branca mestra (o la seva branca equivalent). Això és ideal per executar correccions d'errors i funcions noves que encara no s'han publicat, i quan es treballa amb un error que esteu informant, inclòs si heu de verificar que no es tracta d'un error que s'hagi corregit per una confirmació que encara no està en una versió. Aquests paquets s'han de considerar potencialment inestables. Dit això, malauradament, de vegades no hi ha alternativa perquè alguns responsables de manteniment no etiqueten mai les versions o passen massa temps entre les versions d'etiquetatge i esperen que tothom faci servir la seva confirmació més recent. Depenent del paquet, és possible que siguis la primera persona a provar d'executar aquest commit. Depenent dels desenvolupadors amunt, és possible que la seva darrera confirmació ni tan sols es compile,

És important entendre un error comú. No marquis un paquet de desenvolupament AUR com a obsolet simplement perquè mostra un número de versió antic! Els PKGBUILDfitxers de paquets de desenvolupament contenen una funció addicional pkgver(), que s'utilitza per analitzar automàticament una actualització PKGVERdel codi font de l'amunt. Un format comú per a un -gitpaquet és <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Un paquet podria aparèixer a l'AUR com a 5.0.0.r102.8d7b42ac21-1, perquè això és el que PKGBUILDconté. Però, quan creeu un paquet, YOUR BUILDERs'actualitzarà automàticament PKGVERper reflectir el codi font recentment descarregat. De fet, si s'han llançat moltes versions noves, però no ha canviat res en el procés de PKGBUILDcreació , aquesta llista d'una versió antiga podria acabar construint alguna cosa molt més nova, com ara9.1.2.r53.2c9a41b723-1. Per a aquests paquets, la versió que apareix al lloc web és simplement l'última versió en el moment en què el responsable de l'AUR va haver d'actualitzar per última vegada el fitxer PKGBUILD.

Els mantenedors d'AUR NO haurien d'actualitzar només PKGVERper reflectir les noves versions. Només se suposa que ho fan quan les confirmacions més noves requereixen alguna cosa més PKGBUILDper canviar.

Només marqueu un paquet AUR de desenvolupament obsolet si sabeu que alguna cosa està malament. És a dir, realment l'heu provat d'utilitzar i no s'ha pogut compilar o analitzar un nou format correctament PKGVER. De vegades succeeixen coses que obliguen el responsable de l'AUR a actualitzar el PKGBUILD, com ara canvis de dependències aigües amunt, canvis d' configureopcions, noves versions de GCC recullen errors al codi font que les anteriors no, canvien les ubicacions dels dipòsits aigües amunt o els desenvolupadors aigües amunt canviaran la seva versió habitual. es troba dins del codi font trencant elPKGVERfunció d'anàlisi. Entengueu que, fins i tot si falla en la compilació o el funcionament, això podria significar que el responsable de l'AUR ha de fer canvis al seu procés de creació, o pot ser un problema amb el seu codi font del qual el responsable de l'AUR no té cap responsabilitat.

Paquets obsolets

Assegureu-vos de llegir la secció "Paquets de desenvolupament AUR" anterior, abans d'informar d'un paquet com a obsolet.

Si upstream ha llançat una versió més nova per a un paquet que no és de desenvolupament que al PKGBUILD, podeu fer clic a "Marca el paquet obsolet" i escriure un missatge al responsable. Utilitzeu https://packages.archlinux.org per als paquets de repositoris oficials i https://aur.archlinux.org per als paquets AUR. Un missatge útil seria el número de la nova versió, i potser un enllaç a l'anunci de llançament o al codi font. La funció de marcatge envia automàticament el vostre missatge per correu electrònic al responsable.

En un paquet AUR, si no hi ha hagut resposta després de 2 setmanes, podeu fer clic a "Envia sol·licitud" amb el tipus "Orfe", si voleu demanar a un usuari de confiança que elimini el responsable actual i deixi el paquet orfe, si el responsable no respon a la sol·licitud orfe. En general, les persones només presenten sol·licituds òrfenes si poden i estan disposades a fer-se càrrec del paquet, i preferiblement només si ja tenen un corrent de treball PKGBUILD.

Mentrestant, sovint podeu actualitzar vosaltres mateixos un paquet obsolet. Sovint només cal que canvieu un PKGBUILDactualitzant el PKGVERnúmero de versió al nou número i les sumes d'integritat s'actualitzen. Existeix un programa updpkgsumsal paquet pacman-contrib, que calcula automàticament les sumes i les actualitza al PKGBUILDvostre compte. Val la pena revisar les notes de la versió de upstream, per veure si esmenten que cal canviar alguna cosa durant el procés d'instal·lació de la nova versió. De vegades, els canvis aigües amunt requereixen més canvis o revisions a PKGBUILD/ETC. Sovint, la sourcematriu s'hi incrusta PKGVER, de manera que sovint ni tan sols necessita actualització.