Utilizzo di Devtools su Arch Linux

• Compilazione usando Devtools
• File di configurazione di Devtools
• Deposito locale
• Pacchetto più veloce

Il pacchetto Devtools è stato originariamente creato per utenti fidati per creare correttamente pacchetti per i repository ufficiali. Tuttavia, può essere utilizzato anche dagli utenti ordinari per creare pacchetti AUR o persino pacchetti ufficiali modificati.

Fare riferimento a questa guida per comprendere e utilizzare l'AUR in generale, incluso ottenere PKGBUILD. Questo documento mostra solo i passaggi specifici di Devtools, se è il metodo scelto per compilare un pacchetto.

Devtools mantiene un'installazione Arch separata pulita, situata in /var/lib/archbuild/<TARGET>/root, che contiene solo gruppi di pacchetti basee base-devel. Se questa installazione pulita non esiste, la crea automaticamente. Se esiste, aggiorna automaticamente tutti i pacchetti in esso contenuti. Quando Devtools viene utilizzato per creare un pacchetto, inizia con una copia di questa installazione pulita, installa i pacchetti richiesti solo nella copia, copia il codice sorgente in esso, esegue la compilazione e il packaging in esso e copia solo il pacchetto risultante, in forma identica a quanto si trova nei repository ufficiali.

Devtools offre vantaggi rispetto all'esecuzione makepkgdiretta. Un vantaggio è che base-devele altri pacchetti necessari per compilare, ma non eseguire, il pacchetto che stai creando non finiscono mai nel tuo sistema principale. Si tratta di meno pacchetti da aggiornare periodicamente e di cui preoccuparsi. Sebbene principalmente un vantaggio per i manutentori dei pacchetti Arch, questo processo espone facilmente quando un PKGBUILDnon è corretto, come nel caso in cui manchi una dipendenza dall'elenco che il manutentore ha già installato nel loro sistema principale. È inoltre possibile utilizzare una macchina più veloce nella creazione di pacchetti e copiare il pacchetto risultante in una macchina più lenta che lo eseguirà, senza inquinare l'installazione della macchina di costruzione.

Lo svantaggio principale è che la radice pulita è sempre lì, impiegando circa 800 MB, e di solito una singola copia è lì che occupa più spazio. Nota, se /var/lib/archbuild/usa Btrfs, la copia della radice pulita inizia come un'istantanea di Btrfs, quindi quei file non occupano il doppio dello spazio. La radice pulita viene sempre mantenuta lì per evitare di reinstallarla ogni volta che viene creato un pacchetto.

Compilazione usando Devtools

Installa Devtools:

# pacman -S devtools

Per creare un pacchetto, Devtools include archbuild, ma non lo si esegue direttamente. Include anche collegamenti simbolici di {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. Il link simbolico utilizzato per eseguirlo verrà ispezionato archbuild, per determinare quale target si desidera utilizzare. Può essere eseguito per utilizzare questi repository instabili / di gestione temporanea / test, che potrebbero avere versioni più recenti rispetto a quelle rilasciate ai repository ufficiali. Per utilizzare i repository ufficiali per i pacchetti non AUR, nella directory con PKGBUILD, ad esempio la directory creata da git clone, eseguire quanto segue:

$ extra-x86_64-build

Nota: il resto di questa guida farà semplicemente riferimento extra-x86_64-build.

Al termine dell'esecuzione, saranno i seguenti risultati:

• /var/lib/archbuild/extra-x86_64/root- Un chroot pulito , che è un'installazione aggiornata con solo gruppi di pacchetti basee base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- Questo conterrà un chroot di build . Questa è una copia del chroot pulito con tutte le dipendenze richieste per compilare o eseguire il pacchetto che viene creato, nonché il suo codice sorgente, i risultati della compilazione e il pacchetto.
• La directory in cui ti trovi contiene il pacchetto e crea i file di registro, nonché qualsiasi codice sorgente scaricato.

Alla fine, potresti notare " Checking PKGBUILD" e " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz". Tutte le righe successive vengono emesse namcap, che cerca automaticamente problemi come PKGBUILDfile non validi , dipendenze incluse che il pacchetto non sembra utilizzare, dipendenze non incluse che il pacchetto sembra utilizzare e altro ancora. I falsi positivi sono spesso generati da namcap, ma è un ottimo strumento per dare cose da investigare. Se il tuo pacchetto funziona correttamente, non è una buona idea avvisare il manutentore namcapdell'output, a meno che tu non lo abbia esaminato e verificato che sia necessario apportare una modifica.

È possibile utilizzare pacmanper installare il pacchetto, che installerà tutte le dipendenze richieste per eseguire il pacchetto purché si trovino in repository ufficiali o in un repository locale.

Utilizzare un repository locale come spiegato qui oppure installare direttamente il file:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

Se dovessi eseguire di extra-x86_64-buildnuovo, in questo momento o in qualsiasi momento in seguito con questo o un altro pacchetto, aggiornerà il chroot pulito, se necessario, eliminerà il chroot di build e lo renderà una nuova copia del chroot pulito ed eseguirà lo stesso processo. Se la tua directory ha ancora il codice sorgente scaricato dall'ultima volta, lo utilizzerà. Se il pacchetto è un pacchetto AUR evolutivo, trarrà nuove modifiche anziché ripetere la clonazione.

Internamente, extra-x86_64-buildesegue makechrootpkg, che chiama internamente makepkg. Le opzioni per extra-x86_64-buildincludono quanto segue:

• -c: Pulisce i chroot, rimuovendo e ricreando l'intera /var/lib/archbuild/extra-x86_64/directory, inclusi i chroot puliti e tutte le directory chroot create. Ciò è raramente necessario, solo se il chroot pulito viene danneggiato o se Devtools viene aggiornato in modo da interrompere la compatibilità con le versioni precedenti.
• -r <dir>: Usa una directory diversa da quella /var/lib/archbuild/extra-x86_64/per contenere i chroot.

Eventuali argomenti a extra-x86_64-buildafter --vengono passati a makechrootpkgquando lo utilizza internamente. Numerosi argomenti vengono sempre passati automaticamente da extra-x86_64-builda makechrootpkg. Questi argomenti automatici sono -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n. Dicono makechrootpkgdi rimuovere il chroot di build e renderlo una nuova copia del chroot pulito e di eseguirlo namcapsul pacchetto se viene compilato correttamente. Un'opzione comunemente usata a cui è possibile passare makechrootpkgè -l <copy name>. Questo è il nome della directory per dare il chroot di build, invece di <USERNAME>, che è utile per mantenere più copie o compilare più pacchetti contemporaneamente.

Eventuali argomenti a makechrootpkgafter --vengono passati a makepkg, quando lo utilizza internamente per compilare il pacchetto. La prima volta makepkgviene eseguito makechrootpkg, viene eseguito con le proprie opzioni immutabili, per scaricare i file di origine, se necessario, ed eseguire controlli di integrità; quindi nulla può essere inoltrato in questa corsa. Viene eseguito makepkguna seconda volta per compilare il pacchetto e passa sempre automaticamente makepkgargomenti di --syncdeps --noconfirm --log --holdver --skipintegcui indica makepkg, all'interno della build chroot, di installare automaticamente le dipendenze mancanti necessarie per compilare e utilizzare il pacchetto, per non chiedere conferma durante pacman, registrare il processo di compilazione su testo Inoltre stdout, non aggiornare il codice sorgente se presente in un sistema di controllo versione e non eseguire controlli di verifica dei file sorgente.

Puoi raggrupparli insieme usando il seguente modulo:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

Si noti che /var/lib/archbuildpuò essere trattato come se fosse una directory temporanea. Se hai più dischi rigidi Vultr, vale la pena montare qui un filesystem RAID0 (stripe). Se hai molta RAM, puoi anche montare un file system con supporto RAM come tmpfs. Dopo che un pacchetto è stato creato, viene copiato nella directory da cui è stato eseguito extra-x86_64-builde, se lo si desidera, a questo punto è possibile eliminarlo /var/lib/archbuild. La prossima corsa sarebbe più lenta, perché avrebbe bisogno di creare una nuova radice pulita. In alternativa, è possibile eliminare /var/lib/archbuild/<USERNAME>per recuperare spazio aggiuntivo dal chroot di build prima che venga automaticamente eliminato dalla prossima esecuzione di Devtools. Quindi, anche se qui avessi un filesystem RAID0 fallito, la maggior parte che perderesti sarebbe una compilation in corso.

File di configurazione di Devtools

Ci sono alcuni dettagli da notare con i file di configurazione di Devtools. Si trovano in /usr/share/devtools/, come makepkg-x86_64.confe pacman-extra.conf:

• Per /etcfile come makepkg.confe pacman.conf, puoi tranquillamente modificarli sul posto e quando il pacchetto viene aggiornato, non sovrascriverà le tue modifiche. Piuttosto salverà i nuovi file di configurazione (se modificati dalla versione precedente) che terminano con .pacnew. Tuttavia, i file di configurazione di Devtools /usr/share/non sono destinati a essere modificati dall'utente, quindi quando viene aggiornato Devtools sovrascriverà completamente le modifiche a questi file senza avvisare l'utente. Una modifica a questo comportamento è stata proposta e respinta, poiché ciò aiuta a garantire che i pacchetti vengano inviati ai repository ufficiali tutti con le stesse impostazioni di compilazione.
• Il valore per MAKEFLAGS, PACKAGERe {SRC,SRCPKG,PKG,LOG}DESTsono presi /etc/makepkg.confpiuttosto che da /usr/share/devtools/makepkg-x86_64.conf.

Deposito locale

Se stai creando pacchetti che hanno dipendenze da altri pacchetti che hai creato, devi usare un repository locale, in modo che quando pacmanviene eseguito all'interno del chroot di build, trova le dipendenze.

Per impostare un repository locale, consultare la sezione "Repository locale" di questa guida .

Crea un target personalizzato:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

Modifica /usr/share/devtools/pacman-custom.confe aggiungi quanto segue alla fine:

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

Modifica /etc/pacman.confe aggiungi quanto segue. Questo impone che la directory venga montata nel chroot:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

Ora, invece di usare extra-x86_64-buildusa questo:

$ custom-x86_64-build

Se si desidera sempre utilizzare la destinazione personalizzata, è possibile eliminare la /var/lib/archbuild/extra-x86_64-build/directory se esiste, poiché i chroot saranno ora presenti /var/lib/archbuild/custom-x86_64-build/.

Pacchetto più veloce

Nota che abilitare il pacchetto threaded comporta la modifica dei /usr/share/devtoolsfile di configurazione, che non è ufficialmente supportata, quindi dovrai eseguire questa modifica ogni volta che Devtools viene aggiornato.

Devtools combina un intero pacchetto in un formato di archivio. Per impostazione predefinita, .tar.xzutilizza un singolo thread per la xzcompressione.

Su sistemi con più CPU, è possibile consentire xzl'utilizzo di più thread modificando /usr/share/devtools/makepkg-x86_64.confe modificando la seguente riga:

COMPRESSXZ=(xz -c -z -)

Per consentire tutti i thread quanti sono i core virtuali:

COMPRESSXZ=(xz -c -z - --threads=0)

Per consentire l'utilizzo di più core virtuali, ma non tutti, in modo da ridurre l'impatto sulle prestazioni complessive del sistema, aggiungere un numero specifico:

COMPRESSXZ=(xz -c -z - --threads=21)

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

Se non ti dispiace che il file del pacchetto sia (potenzialmente molto) più grande, disabilita la compressione modificando /usr/share/devtools/makepkg-x86_64.confe modifica la seguente riga:

PKGEXT='.pkg.tar.xz'

Modificalo per assomigliare al seguente:

PKGEXT='.pkg.tar'