Creazione di pacchetti su Arch Linux (incluso AUR)

• PKGBUILD
• Ottenere PKGBUILD / ETC
• Aggiornamento di PKGBUILD / ETC
• compilazione
• Deposito locale
• Compila più velocemente
• Errore firma PGP
• Pacchetti di sviluppo AUR
• Pacchetti obsoleti

Su Arch Linux, i repository ufficiali sono: core, extra e community. Questi pacchetti sono già compilati e vengono installati tramite pacman. Per la maggior parte, gli utenti generici possono ignorare che questi 3 repository ufficiali sono separati. Core contiene i pacchetti più critici, come kernel, processo di avvio, rete, gestione dei pacchetti, openssh e così via. Ha anche requisiti più severi per test più approfonditi prima che vengano rilasciate nuove versioni. Extra contiene altri pacchetti popolari che non sono così importanti, come un server X, i gestori di finestre o i browser web. La community contiene pacchetti meno popolari. Solo gli utenti fidati (circa 60 utenti attivi che sono stati votati da altri utenti fidati) hanno accesso per apportare modifiche ai repository ufficiali.

Nel 2019, ci sono circa 11.000 pacchetti nei repository ufficiali, su https://www.archlinux.org/packages . Ma ci sono molti altri programmi disponibili su Linux. Quindi, l'AUR (Arch Linux User Repository) esiste in modo tale che qualsiasi utente Arch possa aggiungere un nuovo programma e diventare il suo manutentore, oppure adottare un pacchetto "orfano" senza un manutentore attuale. Ci sono circa 55.000 pacchetti nell'AUR, su https://aur.archlinux.org/ .

Esistono 3 differenze critiche con AUR:

1. Ancora una volta, questi pacchetti possono essere prodotti da qualsiasi utente, anche uno nuovo di zecca.
2. L'AUR ospita solo un PKGBUILD, uno script di shell per creare automaticamente il pacchetto, non binari compilati. (A volte contiene anche piccole patch di testo o installa / aggiorna / disinstalla script shell). Questo ha fatto un lavoro straordinario, consentendo a qualsiasi utente di contribuire, riducendo al contempo la possibilità che qualcuno sia in grado di distribuire codice dannoso. La comunità Arch è ancora abbastanza utile per quanto riguarda i problemi con i pacchetti AUR, ma si noti che l'uso di questi è a proprio rischio. Poiché tutto ciò che fornisce è un PKGBUILD, alla fine è tua responsabilità rivedere un PKGBUILDche stai per utilizzare. (Certo, molti utenti non lo fanno e si affidano ad altri per tenere d'occhio.)
3. Poiché pacmannon interagisce direttamente con AUR, è responsabilità dell'utente aggiornare i pacchetti AUR. Quando esegui periodicamente l'aggiornamento dell'intero sistema pacman, non scaricherà automaticamente gli aggiornamenti dei PKGBUILDfile AUR , li compili e li installa per te.

Sebbene questo articolo si concentri sulla creazione di pacchetti dall'AUR, le stesse tecniche possono essere utilizzate per creare pacchetti dai repository ufficiali da soli.

PKGBUILD

Rispetto a un .specfile utilizzato da molte altre distribuzioni, a PKGBUILDè uno script shell breve e semplice. Sebbene alcuni pacchetti siano più complessi, possono semplicemente essere simili ai seguenti:

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
}

Questo documento fa riferimento a:

• PKGNAME: Il nome di un pacchetto
• PKGVER: La versione di un pacchetto (quasi sempre corrispondente al numero di versione di upstream)
• PKGREL: La "versione" di Arch PKGBUILDper una specifica PKGVER(normalmente 1, ma incrementata se è necessario apportare modifiche a una versione a PKGBUILDmonte)
• ARCH: Le architetture su cui il pacchetto può essere costruito (in qualche modo legacy, poiché i repository ufficiali Arch Linux supportano solo "x86_64" (CPU a 64 bit), ma i pacchetti AUR possono ancora supportare "i686" (CPU a 32 bit) o ​​"qualsiasi" designare l'architettura è irrilevante)
• PKGBUILD/ETC: Tutti i file effettivamente presenti nel repository AUR; the PKGBUILDe qualsiasi altra piccola patch di testo o installa / aggiorna / disinstalla gli script della shell. Non include i file upstream sourcenell'array.

Sebbene l'AUR abbia dimostrato di essere estremamente affidabile, è una buona idea guardare a PKGBUILD/ETCper assicurarsi che stia ottenendo la fonte da un luogo di cui ti fidi; (ad esempio, una posizione ufficiale a monte, che può provenire da github - ma non solo un repository github di una persona a caso che non è correlato al pacchetto upstream); e che il PKGBUILD/ETCnon contiene alcun codice sospetto.

Ottenere PKGBUILD/ETC

Dall'AUR

Se i repository ufficiali non contengono un pacchetto che stai cercando di installare, cercalo su https://aur.archlinux.org/ . Spero che troverai che ciò che stai cercando esiste, è aggiornato e mantenuto.

Il modo migliore per ottenere PKGBUILD/ETCl'AUR è clonarlo tramite git.

Installa git, se non lo è già:

# pacman -S git

Utilizzare "URL clone Git" mostrato sul sito Web AUR per quel pacchetto:

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

Inserisci la directory e guarda il suo contenuto. (Tutto elencato qui, ad eccezione di . .. .gitè il PKGBUILD/ETC):

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

Se si esamina PKGBUILD, si spera che vedrà che utilizza il codice sorgente upstream ufficiale ed esegue i passaggi tipici per creare un pacchetto, quindi sembra affidabile. Il file .SRCINFOcontiene solo le informazioni mostrate sul pacchetto sul sito Web, quindi non è preoccupante. Se ci sono altri file qui, non sono (direttamente) forniti da upstream, quindi i file e il modo in cui vengono utilizzati PKGBUILDdovrebbero essere esaminati, per assicurarsi che non contengano nulla di sospetto.

Dai repository ufficiali

Sebbene sia richiesto molto meno spesso, è possibile compilare un pacchetto già nei repository ufficiali, per includere una nuova patch, creare una versione più recente, ecc.

Ottieni PKGBUILD/ETCdai repository core e extra:

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

Dal repository della comunità:

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

Aggiornamento PKGBUILD/ETC

Se PKGBUILD/ETCviene rilasciato un aggiornamento , è possibile tornare in questa directory creata utilizzando git clonee aggiornarli:

$ git pull

Quindi, ricompila e aggiorna il pacchetto utilizzando il metodo di tua scelta, di seguito.

compilazione

Esistono molti modi per compilare i pacchetti. Alla fine, tutto usa makepkg. Esistono 2 modi ufficialmente supportati:

• Per utilizzare direttamente makepkg, consultare https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Per utilizzare indirettamente makepkgin modo pulito chroot, consultare https://www.vultr.com/docs/using-devtools-on-arch-linux .

Ci sono molti programmi AUR helper, (come l' makepkginvolucro), che non sono ufficialmente supportati da Arch, ad esempio aurutils, yaye il recentemente sospesi aurmane yaourt. Anche se usi uno di questi altri programmi di supporto, si consiglia vivamente di acquisire familiarità con i modi ufficialmente supportati per essere più efficace quando qualcosa va storto.

Il resto di questo documento utilizzerà YOUR BUILDERper indicare qualunque metodo tu scelga.

Deposito locale

È possibile impostare un repository locale in modo che sia un percorso centrale per tutti i pacchetti creati.

Posiziona il repository locale dove desideri:

# mkdir /archLocalRepo

Esegui YOUR BUILDERsenza alcuna opzione di installazione automatica e copia il pacchetto nel tuo repository locale.

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

Aggiungi il nuovo pacchetto all'indice del repository:

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

Per rimuovere un pacchetto dall'indice del repository e dal file del pacchetto stesso:

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

Se è necessario sostituire un file di pacchetto esistente, è necessario rimuovere separatamente quello da sostituire, quindi aggiungere quello nuovo. Non è possibile semplicemente copiare il nuovo file su quello vecchio.

Configurare pacmanper utilizzare il repository locale, modificando /etc/pacman.confe aggiungere alla fine quanto segue:

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

È necessario pacmanaggiornare le proprie conoscenze sui database (incluso quello locale), sui database; per vedere i pacchetti che hai aggiunto ad esso:

# pacman -Sy

È quindi possibile installare il pacchetto, non diversamente da se fosse in un repository ufficiale:

# pacman -S <PKGNAME>

Nota se il pacchetto è semplicemente una dipendenza di un altro pacchetto che si intende installare, non è necessario installarlo direttamente. Quando installi questo altro pacchetto, pacmantroverà e installerà automaticamente i pacchetti di dipendenza nel tuo repository locale.

Compila più velocemente

Per impostazione predefinita, YOUR BUILDERcompila utilizzando un singolo thread. Su sistemi con più CPU, è possibile consentire l'utilizzo di più thread, ove possibile. Il sistema di compilazione compilerà parti del codice sorgente in parallelo quando può. A volte parti del codice richiedono che altre parti con cui interagisce siano già compilate, quindi non vedrai sempre tutti i thread utilizzati che sono consentiti. Modifica /etc/makepkg.conf.

Per consentire l'utilizzo di tutti i thread quanti sono i core virtuali, aggiungere quanto segue:

MAKEFLAGS="-j$(nproc)"

Nota: questo eseguirà il comando nprocogni volta, quindi utilizzerà sempre il numero corrente di core, nel caso in cui si aggiorni il server Vultr

Per consentire l'utilizzo di più core virtuali, ma non tutti, ad esempio per ridurre l'impatto sulle prestazioni complessive del sistema, aggiungere un numero specifico. Ad esempio, se si dispone di 24 core, è possibile consentire l'utilizzo di 21:

MAKEFLAGS="-j21"

Se si specifica un numero maggiore di thread rispetto al numero di core virtuali disponibili, le prestazioni diminuiranno.

È abbastanza raro, ma i sistemi di compilazione di alcuni pacchetti hanno problemi con la compilazione parallela, dal non definire correttamente le dipendenze tra parti di codice. In genere, i PKGBUILDfile di quei pacchetti gestiranno questo per te invocando make -j1, che sovrascrive il valore predefinito che hai impostato. Se ne ha bisogno e manca, segnalalo al manutentore del pacchetto Arch.

Errore firma PGP

Un PKGBUILDarray di origine può contenere .asco .sigfile. Sono spesso inclusi usando l'espansione bash brace, quindi può essere facile perdere:

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

Se uno di questi formati di file di firma è incluso nell'array di origine, YOUR BUILDERtenta automaticamente di verificare la firma dell'archivio di origine upstream. La chiave PGP della firma deve trovarsi nel portachiavi dell'utente; altrimenti, si interromperà con l'errore:

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

È importante capire che una chiave GPG può essere mostrata in diversi modi. L'impronta digitale è di 40 caratteri esadecimali ed è quello che dovresti sempre usare. Un ID chiave lungo è le ultime 16 cifre e un ID chiave breve è le ultime 8 cifre. Sebbene più breve sia conveniente, consente duplicati che annullano l'intero ragionamento dietro la verifica delle firme. Peggio ancora, è noto che gli aggressori generano chiavi false che corrispondono a chiavi di lunghezza inferiore per sviluppatori di alto profilo.

Ottenere e verificare l'impronta digitale della chiave PGP

Se non hai già provato a creare il pacchetto, scarica i sorgenti che includeranno il file della firma: (Se hai provato a costruire, sarà già lì)

$ makepkg --nobuild --noextract

Per ottenere l'impronta digitale completa:

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

Idealmente, dovresti verificare questa impronta digitale da monte. Per sicurezza, a monte dovrebbe fornire le chiavi dei suoi manutentori da qualche parte sul suo sito Web o nella fonte. La semplice ricerca della chiave su un key server non sta realmente facendo nulla. Un utente malintenzionato può inviare facilmente una chiave falsa, poiché i server delle chiavi non verificano l'autenticità. Le chiavi possono essere firmate da altre chiavi, quindi se hai già una chiave di cui ti fidi, dovresti essere abbastanza sicuro fidandoti di tutte le chiavi che hanno firmato.

Può essere un bel po 'di lavoro, specialmente quando upstream non pubblica la propria impronta digitale o la posiziona in un posto facile da trovare. Il PKGBUILDconterrà una validpgpkeysmatrice, che sono stati aggiunti dal manutentore Arch. Se il pacchetto è un repository ufficiale, significa che un utente fidato lo ha inserito lì e dovresti essere abbastanza sicuro di fidarti di tutto ciò che è elencato nell'array. Se il pacchetto si trova nell'AUR, ricorda che significa che è stato inserito da un altro utente Arch. Se sei preoccupato di fidarti, puoi sempre guardare l'utente per vedere cosa hanno fatto in passato con Arch.

Aggiungi chiave PGP al tuo portachiavi

Per aggiungere l'impronta digitale al tuo portachiavi:

$ gpg --recv-keys <FINGERPRINT>

Ora puoi eseguire YOUR BUILDERe si fiderà dell'impronta digitale.

Pacchetti di sviluppo AUR

Pacchetti di AUR con nomi che terminano -git, -svn, -bzro -hgsono versioni di sviluppo, che utilizzano del monte più recente sistema di controllo della versione impegnano invece a monte è ultima release. Ad esempio, a-gitil pacchetto userebbe l'ultimo commit di upstream nel ramo master (o il loro ramo equivalente). Questo è ottimo per eseguire correzioni di bug a monte e nuove funzionalità che non sono ancora state rilasciate, e quando lavori con upstream su un bug che stai segnalando, incluso se è necessario verificare per loro che non è un bug corretto da un commit non ancora in una versione. Questi pacchetti devono essere considerati potenzialmente instabili. Detto questo, sfortunatamente, a volte non c'è alternativa perché alcuni manutentori a monte non taggano mai le versioni o vanno troppo a lungo tra le versioni di tag e si aspettano che tutti utilizzino il loro commit più recente. A seconda del pacchetto, potresti essere il primo a provare a eseguire quel commit. A seconda degli sviluppatori upstream, il loro ultimo commit potrebbe non essere nemmeno compilato,

È importante capire un errore comune. Non contrassegnare un pacchetto di sviluppo AUR come obsoleto semplicemente perché mostra un vecchio numero di versione! I PKGBUILDfile del pacchetto di sviluppo contengono una funzione aggiuntiva pkgver(), che viene utilizzata per analizzare automaticamente un PKGVERcodice sorgente upstream aggiornato . Un formato comune per un -gitpacchetto è <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Un pacchetto potrebbe essere elencato in AUR come 5.0.0.r102.8d7b42ac21-1, perché è quello che PKGBUILDcontiene. Ma, quando crei un pacchetto, YOUR BUILDERsi aggiornerà automaticamente PKGVERper riflettere il codice sorgente appena scaricato. In effetti, se sono state rilasciate molte nuove versioni, ma nulla è cambiato nel processo di compilazione, tale PKGBUILDelenco di una versione precedente potrebbe finire con la creazione di qualcosa di molto più nuovo, come9.1.2.r53.2c9a41b723-1. Per questi pacchetti, la versione elencata sul sito Web è semplicemente l'ultima versione al momento in cui il manutentore AUR ha dovuto aggiornare l'ultima volta PKGBUILD.

I manutentori di AUR NON devono semplicemente aggiornare PKGVERper riflettere le nuove versioni. Dovrebbero farlo solo quando i nuovi commit a monte richiedono effettivamente qualcos'altro PKGBUILDper cambiare.

Contrassegna un pacchetto AUR di sviluppo non aggiornato solo se sai che qualcosa non va. Significato, hai effettivamente provato a usarlo e non riesce a compilare o analizzare un nuovo formattato correttamente PKGVER. A volte accadono cose che costringono il manutentore di AUR ad aggiornare PKGBUILD, come cambiano le dipendenze a monte, cambiano le configureopzioni, le nuove versioni di GCC rilevano errori nel codice sorgente che le precedenti non hanno fatto, cambiano le posizioni dei repository a monte o gli sviluppatori a monte cambieranno dove la loro versione tipica è all'interno del codice sorgente che rompe ilPKGVERfunzione di analisi. Capire che anche se non riesce a compilare o funzionare, ciò potrebbe significare che il manutentore AUR deve apportare modifiche al proprio processo di compilazione, oppure potrebbe essere un problema a monte con il loro codice sorgente di cui il manutentore AUR non ha alcuna responsabilità.

Pacchetti obsoleti

Assicurati di leggere la sezione "Pacchetti di sviluppo AUR" sopra, prima di segnalare che un pacchetto è obsoleto!

Se upstream ha rilasciato una versione più recente per un pacchetto non evolutivo rispetto al pacchetto PKGBUILD, è possibile fare clic su "Contrassegna pacchetto non aggiornato" e digitare un messaggio per il manutentore. Utilizzare https://packages.archlinux.org per i pacchetti di repository ufficiali e https://aur.archlinux.org per i pacchetti AUR. Un messaggio utile sarebbe il nuovo numero di versione e forse un collegamento all'annuncio di rilascio o al codice sorgente. La funzione di segnalazione invia automaticamente il tuo messaggio al manutentore.

Su un pacchetto AUR, se non ci sono risposte dopo 2 settimane, puoi fare clic su "Invia richiesta" con il tipo "Orphan", se desideri chiedere a un utente fidato di rimuovere l'attuale manutentore e rendere il pacchetto orfano, se il manutentore non risponde alla richiesta orfana. In genere, le persone archiviano richieste orfane solo se sono in grado e sono disposte ad assumere il pacchetto, e preferibilmente solo se hanno già una corrente funzionante PKGBUILD.

Nel frattempo, puoi spesso aggiornare tu stesso un pacchetto obsoleto. Spesso è sufficiente modificare a PKGBUILDaggiornando PKGVERil nuovo numero di versione e le somme di integrità devono essere aggiornate. updpkgsumsEsiste un programma nel pacchetto pacman-contrib, che calcola automaticamente le somme e le aggiorna al posto PKGBUILDtuo. Vale la pena controllare le note di rilascio di upstream, per vedere se menzionano che qualcosa deve cambiare durante il processo di installazione della nuova versione. A volte i cambiamenti a monte richiedono più cambiamenti o revisioni PKGBUILD/ETC. Spesso l' sourcearray si incorpora PKGVERin esso, quindi spesso non è nemmeno necessario aggiornarlo.