Paket Bangunan di Arch Linux (Termasuk AUR)

• PKGBUILD
• Memperoleh PKGBUILD / DLL
• Meningkatkan PKGBUILD / ETC
• Kompilasi
• Repositori Lokal
• Kompilasi Lebih Cepat
• Kesalahan Tanda Tangan PGP
• Paket Pengembangan AUR
• Paket yang sudah ketinggalan zaman

Di Arch Linux, repositori resmi adalah: inti, ekstra, dan komunitas. Paket-paket ini sudah dikompilasi, dan mereka diinstal melalui pacman. Sebagian besar, pengguna umum dapat mengabaikan bahwa 3 repositori resmi ini terpisah. Core berisi paket-paket paling kritis, seperti kernel, proses boot, jaringan, manajemen paket, openssh dan sebagainya. Ini juga memiliki persyaratan yang lebih ketat untuk pengujian yang lebih menyeluruh sebelum versi baru dirilis. Ekstra berisi paket populer lainnya yang tidak sepenting, seperti server X, pengelola jendela atau browser web. Komunitas berisi paket yang kurang populer. Hanya Pengguna Tepercaya (sekitar 60 pengguna aktif yang dipilih oleh Pengguna Tepercaya lainnya) yang memiliki akses untuk melakukan perubahan pada repositori resmi.

Pada tahun 2019, ada sekitar 11.000 paket di repositori resmi, di https://www.archlinux.org/packages . Tetapi, ada banyak program lain yang tersedia di Linux. Jadi, AUR (Arch Linux User Repository) ada sehingga setiap pengguna Arch dapat menambahkan program baru dan menjadi pemeliharanya, atau mengadopsi paket "yatim" tanpa pengurus saat ini. Ada sekitar 55.000 paket di AUR, di https://aur.archlinux.org/ .

Ada 3 perbedaan kritis dengan AUR:

1. Sekali lagi, paket-paket ini dapat diproduksi oleh pengguna mana pun, bahkan yang baru.
2. AUR hanya menampung a PKGBUILD, skrip shell untuk secara otomatis membuat paket, bukan binari yang dikompilasi. (Kadang-kadang juga berisi tambalan teks kecil, atau install / upgrade / uninstall skrip shell). Ini telah melakukan pekerjaan luar biasa yang memungkinkan pengguna mana pun untuk berkontribusi, sambil mengurangi kemungkinan seseorang dapat mendistribusikan kode berbahaya. Komunitas Arch masih sangat membantu mengenai masalah dengan paket AUR, tetapi perlu dicatat bahwa penggunaannya adalah risiko Anda sendiri. Karena semua yang disediakannya adalah PKGBUILD, pada akhirnya tanggung jawab Anda untuk meninjau PKGBUILDyang akan Anda gunakan. (Memang, banyak pengguna tidak melakukan ini dan hanya mengandalkan orang lain untuk berjaga-jaga.)
3. Karena pacmantidak berinteraksi langsung dengan AUR, Anda bertanggung jawab untuk memperbarui paket AUR. Ketika Anda memutakhirkan seluruh sistem Anda secara berkala pacman, itu tidak akan secara otomatis mengunduh pembaruan ke PKGBUILDfile AUR , mengkompilasinya, dan menginstalnya untuk Anda.

Meskipun artikel ini berfokus pada membangun paket dari AUR, teknik yang sama dapat digunakan untuk membangun paket dari repositori resmi sendiri.

PKGBUILD

Dibandingkan dengan .specfile yang menggunakan banyak distribusi lainnya, a PKGBUILDadalah skrip shell yang pendek dan sederhana. Meskipun beberapa paket lebih kompleks, mereka dapat mirip dengan yang berikut:

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
}

Dokumen ini mengacu pada:

• PKGNAME: Nama paket
• PKGVER: Versi paket (hampir selalu cocok dengan nomor versi upstream)
• PKGREL: Lengkungan "versi" PKGBUILDuntuk untuk yang spesifik PKGVER(biasanya 1, tetapi bertambah jika perubahan harus dibuat untuk PKGBUILDantara rilis upstream)
• ARCH: Arsitektur paket dapat dibangun di atas (agak warisan, karena repositori resmi Arch Linux hanya mendukung "x86_64" (CPU 64-bit), tetapi paket AUR masih dapat mendukung "i686" (32-bit CPU) atau "apa saja" menetapkan arsitektur tidak relevan)
• PKGBUILD/ETC: File apa pun yang sebenarnya ada di repositori AUR; yang PKGBUILD, dan setiap patch teks kecil lainnya, atau menginstal / upgrade / skrip shell uninstall. Tidak termasuk file hulu dalam sourcearray.

Meskipun AUR telah terbukti sangat dapat dipercaya, adalah ide yang baik untuk melihat a PKGBUILD/ETCuntuk memastikan sumbernya berasal dari tempat yang ingin Anda percayai; (misalnya, lokasi hulu resmi, yang bisa dari github - tetapi bukan hanya repositori github orang acak yang tidak terkait dengan paket hulu); dan bahwa PKGBUILD/ETCtidak mengandung kode tersangka.

Memperoleh PKGBUILD/ETC

Dari AUR

Jika repositori resmi tidak berisi paket yang ingin Anda instal, cari di https://aur.archlinux.org/ . Mudah-mudahan, Anda akan menemukan bahwa apa yang Anda cari ada, mutakhir dan dipertahankan.

Cara terbaik untuk mendapatkan PKGBUILD/ETCdari AUR adalah dengan mengkloningnya git.

Instal git, jika belum:

# pacman -S git

Gunakan "Git Clone URL" yang ditampilkan di situs web AUR untuk paket itu:

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

Masukkan direktori dan lihat isinya. (Semua yang tercantum di sini, kecuali untuk . .. .gitadalah PKGBUILD/ETC):

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

Jika Anda memeriksa PKGBUILD, mudah-mudahan Anda akan melihatnya menggunakan kode sumber hulu resmi, dan melakukan langkah-langkah khas untuk membangun sebuah paket, sehingga tampaknya dapat dipercaya. The .SRCINFOhanya berisi informasi yang ditampilkan pada situs web tentang paket, jadi tidak mengkhawatirkan. Jika ada file lain di sini, mereka tidak (langsung) disediakan oleh upstream, jadi file dan bagaimana mereka digunakan dalam PKGBUILDharus diperiksa, untuk memastikan mereka tidak mengandung tersangka apa pun.

Dari Repositori Resmi

Meskipun diperlukan lebih jarang, Anda dapat membuat paket yang sudah ada di repositori resmi, untuk menyertakan tambalan baru, membuat versi yang lebih baru, dll.

Dapatkan PKGBUILD/ETCdari repositori inti dan ekstra:

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

Dari repositori komunitas:

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

Perbaikan PKGBUILD/ETC

Jika pemutakhiran PKGBUILD/ETCdirilis, Anda dapat kembali ke direktori ini yang dibuat menggunakan git clone, dan memperbaruinya:

$ git pull

Kemudian, kompilasi ulang dan tingkatkan paket menggunakan metode pilihan Anda, di bawah ini.

Kompilasi

Ada banyak cara untuk mengkompilasi paket. Pada akhirnya, semuanya menggunakan makepkg. Ada 2 cara yang didukung secara resmi:

• Untuk langsung menggunakan makepkg, lihat https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Untuk menggunakan secara tidak langsung makepkgdalam bersih chroot, lihat https://www.vultr.com/docs/using-devtools-on-arch-linux .

Ada banyak program AUR pembantu, (seperti makepkgpembungkus), yang tidak secara resmi didukung oleh Arch, seperti aurutils, yay, dan baru-baru ini dihentikan aurmandan yaourt. Sekalipun Anda menggunakan salah satu dari program penolong ini, sangat disarankan untuk membiasakan diri dengan cara-cara yang didukung secara resmi agar lebih efektif ketika terjadi kesalahan.

Sisa dari dokumen ini akan digunakan YOUR BUILDERuntuk berarti metode apa pun yang Anda pilih.

Repositori Lokal

Anda dapat mengatur repositori lokal menjadi lokasi sentral untuk semua paket yang Anda buat.

Tempatkan repositori lokal di mana pun Anda suka:

# mkdir /archLocalRepo

Jalankan YOUR BUILDERtanpa opsi instalasi otomatis, dan salin paket ke repositori lokal Anda.

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

Tambahkan paket baru ke indeks repositori:

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

Untuk menghapus paket dari indeks repositori dan file paket itu sendiri:

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

Jika Anda perlu mengganti file paket yang ada, Anda harus menghapus secara terpisah yang diganti, lalu menambahkan yang baru. Anda tidak bisa hanya menyalin file baru dari yang lama.

Konfigurasikan pacmanuntuk menggunakan repositori lokal Anda, dengan mengedit /etc/pacman.conf, dan tambahkan yang berikut di akhir:

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

Anda perlu pacmanmemperbarui pengetahuan tentang repositori, (termasuk yang lokal), basis data; untuk melihat paket yang telah Anda tambahkan ke dalamnya:

# pacman -Sy

Anda kemudian dapat menginstal paket, tidak berbeda dari jika berada di repositori resmi:

# pacman -S <PKGNAME>

Catatan jika paket tersebut hanyalah ketergantungan dari paket lain yang akan Anda instal, Anda tidak perlu menginstalnya secara langsung. Ketika Anda menginstal paket lain ini, pacmansecara otomatis akan menemukan dan menginstal paket dependensi di repositori lokal Anda.

Kompilasi Lebih Cepat

Secara default, YOUR BUILDERkompilasi menggunakan utas tunggal. Pada sistem multi-CPU, Anda dapat mengizinkan menggunakan beberapa utas jika memungkinkan. Sistem build akan mengkompilasi bagian-bagian dari kode sumber secara paralel bila memungkinkan. Terkadang bagian kode memerlukan bagian lain yang berinteraksi dengannya untuk dikompilasi, sehingga Anda tidak akan selalu melihat sebanyak mungkin utas yang digunakan. Edit /etc/makepkg.conf.

Untuk mengizinkan menggunakan sebanyak mungkin utas yang Anda miliki inti virtual, tambahkan berikut ini:

MAKEFLAGS="-j$(nproc)"

Catatan: Ini akan menjalankan perintah nprocsetiap waktu, sehingga akan selalu menggunakan jumlah core saat ini, jika Anda meningkatkan server Vultr Anda

Untuk mengizinkan penggunaan beberapa inti virtual, tetapi tidak semuanya, seperti untuk mengurangi dampak pada kinerja sistem secara keseluruhan, tambahkan angka tertentu. Misalnya, jika Anda memiliki 24 core, Anda dapat mengizinkan 21 untuk digunakan:

MAKEFLAGS="-j21"

Menentukan lebih banyak utas daripada jumlah inti virtual yang Anda miliki akan menurunkan kinerja.

Ini cukup langka, tetapi beberapa sistem build paket memiliki masalah dengan kompilasi paralel, dari tidak mendefinisikan dependensi di antara bagian-bagian kode. Biasanya, PKGBUILDfile paket itu akan menangani ini untuk Anda dengan memanggil make -j1, yang menimpa default yang Anda atur. Jika perlu dan ini tidak ada, laporkan ke pengelola paket Arch.

Kesalahan Tanda Tangan PGP

Sebuah PKGBUILDarray sumber dapat berisi .ascatau .sigfile. Mereka sering disertakan menggunakan ekspansi bash brace, sehingga mudah dilewatkan:

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

Jika salah satu dari format file tanda tangan ini termasuk dalam larik sumber, YOUR BUILDERsecara otomatis mencoba memverifikasi tanda tangan arsip sumber hulu. Kunci PGP tanda tangan harus dalam keyring pengguna; jika tidak, itu akan dibatalkan dengan kesalahan:

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

Sangat penting untuk memahami kunci GPG yang dapat ditunjukkan beberapa cara. Sidik jarinya adalah 40 karakter heksadesimal, dan itulah yang harus selalu Anda gunakan. ID kunci panjang adalah 16 digit terakhir, dan ID kunci pendek adalah 8 digit terakhir. Meskipun lebih pendek nyaman, ini memungkinkan duplikat yang mengosongkan seluruh alasan di balik verifikasi tanda tangan. Lebih buruk lagi, penyerang telah dikenal untuk menghasilkan kunci palsu yang cocok dengan kunci yang kurang panjang untuk pengembang profil tinggi.

Dapatkan dan Verifikasi Sidik Jari Kunci PGP

Jika Anda belum mencoba membuat paket, unduh sumber yang akan menyertakan file tanda tangan: (Jika Anda mencoba membangun, itu sudah ada di sana)

$ makepkg --nobuild --noextract

Untuk mendapatkan sidik jari lengkap:

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

Idealnya, Anda harus memverifikasi sidik jari ini dari hulu. Agar aman, hulu harus memberikan kunci pengelolanya di suatu tempat di situs webnya atau di sumbernya. Hanya mencari kunci di server kunci tidak benar-benar melakukan apa-apa. Seorang penyerang dapat dengan mudah mengirimkan kunci palsu, karena server kunci tidak memverifikasi keaslian. Kunci dapat ditandatangani oleh kunci lain, jadi jika Anda sudah memiliki kunci yang Anda percayai, Anda harus cukup aman mempercayai kunci apa pun yang telah mereka tandatangani.

Itu bisa jadi pekerjaan yang sangat berat, terutama ketika upstream tidak mempublikasikan sidik jari mereka atau meletakkannya di tempat yang mudah ditemukan. The PKGBUILDakan berisi validpgpkeysarray, yang ditambahkan oleh pengelola Arch. Jika paket tersebut adalah repositori resmi, itu berarti Pengguna Tepercaya meletakkannya di sana, dan Anda seharusnya cukup aman untuk memercayai apa pun yang tercantum dalam array. Jika paket berada di AUR, ingat itu hanya berarti bahwa pengguna Arch lain meletakkannya di sana. Jika Anda khawatir tentang mempercayainya, Anda selalu dapat melihat ke pengguna untuk melihat apa yang telah mereka lakukan di masa lalu dengan Arch.

Tambahkan Kunci PGP ke Keyring Anda

Untuk menambahkan sidik jari ke keyring Anda:

$ gpg --recv-keys <FINGERPRINT>

Anda sekarang dapat berlari YOUR BUILDER, dan itu akan mempercayai sidik jari.

Paket Pengembangan AUR

Paket AUR dengan nama yang diakhiri -git, -svn, -bzratau -hgversi perkembangan, yang menggunakan sistem kontrol versi terbaru hulu komit bukan hulu rilis terbaru. Sebagai contoh, a-gitpaket akan menggunakan komit terbaru upstream di cabang utama (atau cabang mereka yang setara.) Ini bagus untuk menjalankan perbaikan bug hulu dan fitur baru yang belum dirilis, dan ketika bekerja dengan hulu pada bug yang Anda laporkan termasuk jika Anda perlu memverifikasi untuk mereka itu bukan bug yang sudah diperbaiki oleh komit yang belum dirilis. Paket-paket ini harus dianggap berpotensi tidak stabil. Yang mengatakan, sayangnya, kadang-kadang tidak ada alternatif karena beberapa pengelola hulu tidak pernah menandai rilis atau berlama-lama di antara rilis tag, dan berharap semua orang menggunakan komit terbaru mereka. Bergantung pada paketnya, Anda mungkin menjadi orang pertama yang mencoba menjalankan komit itu. Bergantung pada pengembang hulu, komit terbaru mereka mungkin bahkan tidak bisa dikompilasi,

Penting untuk memahami kesalahan umum. Jangan tandai paket pengembangan AUR sebagai usang karena hanya menunjukkan nomor versi lama! PKGBUILDFile paket pengembangan berisi fungsi tambahan pkgver(), yang digunakan untuk secara otomatis mengurai pembaruan PKGVERdari kode sumber hulu. Format umum untuk sebuah -gitpaket adalah <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Suatu paket mungkin terdaftar dalam AUR sebagai 5.0.0.r102.8d7b42ac21-1, karena itu adalah apa yang PKGBUILDdikandungnya. Tetapi, ketika Anda membuat paket, YOUR BUILDERakan secara otomatis memperbarui PKGVERuntuk mencerminkan kode sumber yang baru diunduh. Faktanya, jika banyak versi baru telah dirilis, tetapi tidak ada yang berubah dalam proses build, PKGBUILDdaftar seperti itu versi lama dapat akhirnya membangun sesuatu yang jauh lebih baru, seperti9.1.2.r53.2c9a41b723-1. Untuk paket-paket ini, versi yang tercantum di situs web hanyalah versi terbaru pada saat pengelola AUR terakhir harus memperbarui PKGBUILD.

Pengelola AUR TIDAK seharusnya hanya memperbarui PKGVERuntuk mencerminkan versi baru. Mereka hanya seharusnya melakukannya ketika komitmen hulu yang lebih baru sebenarnya membutuhkan sesuatu yang lain PKGBUILDuntuk berubah.

Hanya menandai paket pengembangan AUR yang kedaluwarsa jika Anda tahu ada sesuatu yang salah. Artinya, Anda telah benar-benar mencoba menggunakannya dan gagal mengompilasi atau mem-parsing yang baru diformat dengan benar PKGVER. Kadang-kadang terjadi hal-hal yang memaksa pengelola AUR untuk memperbarui PKGBUILD, seperti perubahan dependensi hulu, configureopsi berubah, versi GCC baru mengambil kesalahan dalam kode sumber yang sebelumnya tidak, lokasi repositori hulu berubah atau pengembang hulu akan berubah di mana versi tipikal mereka ada dalam kode sumber melanggarPKGVERfungsi parsing. Memahami bahwa meskipun gagal mengkompilasi atau bekerja, ini bisa berarti pengelola AUR perlu melakukan perubahan pada proses pembangunan mereka, atau itu bisa menjadi masalah hulu dengan kode sumber mereka yang tidak dipikul oleh pengelola AUR.

Paket yang sudah ketinggalan zaman

Pastikan untuk membaca bagian "Paket Pengembangan AUR" di atas, sebelum melaporkan paket yang kedaluwarsa!

Jika upstream telah merilis versi yang lebih baru untuk paket non-pengembangan daripada di PKGBUILD, Anda dapat mengklik "Tandai paket kedaluwarsa" dan ketik pesan ke pengelola. Gunakan https://packages.archlinux.org untuk paket repositori resmi, dan https://aur.archlinux.org untuk paket AUR. Pesan yang bermanfaat adalah nomor versi baru, dan mungkin tautan ke pengumuman rilis atau kode sumber. Fitur penandaan secara otomatis mengirim email pesan Anda ke pengelola.

Pada paket AUR, jika tidak ada respons setelah 2 minggu, Anda dapat mengklik "Kirim Permintaan" dengan jenis "Orphan", jika Anda ingin meminta Pengguna Tepercaya untuk menghapus pengelola saat ini, dan membuat paket menjadi yatim, jika pengelola tidak menanggapi permintaan anak yatim. Secara umum, orang hanya mengajukan permintaan anak yatim jika mereka mampu dan mau mengambil alih paket, dan lebih baik hanya jika mereka sudah memiliki arus kerja PKGBUILD.

Sementara itu, Anda sering dapat memperbarui paket yang sudah usang sendiri. Seringkali Anda hanya perlu mengubah a PKGBUILDdengan memperbarui PKGVERke nomor versi baru, dan jumlah integritas diperbarui. Sebuah program updpkgsumsada dalam paket pacman-contrib, yang secara otomatis menghitung jumlah dan memperbaruinya PKGBUILDuntuk Anda. Ada baiknya memeriksa catatan rilis upstream, untuk melihat apakah mereka menyebutkan bahwa ada sesuatu yang perlu diubah selama proses instalasi versi baru. Terkadang perubahan hulu membutuhkan lebih banyak perubahan atau perbaikan PKGBUILD/ETC. Seringkali sourcearray tertanam PKGVERdi dalamnya, bahkan seringkali tidak perlu diperbarui.