pkgbuilds

PKGBUILD Garuda Linux

Repositori ini berisi PKGBUILD untuk semua paket yang saat ini berada di repositori garuda . Ini dioperasikan di GitLab karena menggunakan CI-nya secara ekstensif dan memiliki mirror GitHub yang hanya bisa dibaca.

Cakupan repo ini

Semua PKGBUILD kami ada di sini. Secara historis, ini dipecah menjadi repositori mereka sendiri. Untuk mempermudah pencarian PKGBUILD yang benar, serta memungkinkan kontribusi lebih cepat, baru-baru ini kami menggabungkannya ke dalam repositori baru ini. Termasuk semua PKGBUILD paket termasuk file konfigurasinya (ini berlaku untuk file yang lebih kecil seperti garuda-fish-config ). Untuk beberapa di antaranya, seperti paket garuda-*-settings , kontennya mungkin masih dapat ditemukan di repositori masing-masing.

Menemukan masalah?

Jika terjadi masalah pengemasan atau hal serupa, jangan ragu untuk melaporkannya melalui bagian masalah kami. Anda dapat mengklik di sini untuk membuat yang baru.

Bagaimana cara berkontribusi?

Kami sangat menghargai kontribusi apa pun! ? Untuk melakukannya, ikuti langkah-langkah berikut:

• Buat fork dari repositori ini.
• Kloning garpu Anda secara lokal (tutorial singkat git).
• Tambahkan perubahan yang diinginkan pada PGBUILD atau kode sumber.
• Pastikan shellcheck dan shfmt melaporkan tidak ada masalah dengan file yang diubah
  • Ketergantungan yang diperlukan perlu diinstal sebelumnya, misalnya. melalui sudo pacman -S shfmt shellcheck
  • Jalankan skrip lint.sh melalui bash ./.ci/lint.sh periksa kodenya
  • Terapkan saran tertentu secara otomatis melalui bash ./ci/lint.sh apply
• Komit menggunakan pesan komit konvensional dan dorong perubahan apa pun kembali ke fork Anda.
  • Aplikasi komit membantu membuat pesan komit yang sesuai. Anda dapat menginstalnya melalui pip karena saat ini tidak ada paket di repo Arch: pip install --user -U Commitizen . Kemudian dilanjutkan dengan menjalankan cz commit pada folder kloningan.
• Buat permintaan penggabungan baru di repositori utama kami.
• Periksa apakah ada salah satu alur yang berjalan gagal dan terapkan saran pada akhirnya.

Kami kemudian akan meninjau perubahan dan akhirnya menggabungkannya.

Menangani masalah pengemasan tertentu

Paket usang dan rusak

Ada beberapa kasus paket yang tidak digunakan lagi, tidak berguna lagi dan juga menyebabkan sistem tidak dapat diperbarui. Ini dapat ditangani dengan menambahkan paket ke conflicts() dari garuda-common-settings dan auto-pacman dari garuda-update . Hasilnya adalah paket yang melanggar akan dihapus secara otomatis karena konflik.

CI / alat pembuatan

Berikut ini sebagian diambil dari dokumentasi alat pembangunan, menghilangkan informasi yang tidak relevan dengan repo ini. Jika Anda mencari petunjuk pengaturan, harap README lengkapnya.

Umum

Penerapan dapat dipicu secara otomatis dengan mengubah konten di dalam direktori PKGBUILD atau menambahkan [deploy *] ke pesan penerapan. Berbeda dengan pemeriksaan PKGBUILD, pemeriksaan ini hanya tersedia untuk penerapan di cabang main . Yang didukung adalah:

• [deploy all] : Menerapkan rutin garuda penuh, artinya semua PKGBUILD di repositori ini.
• [deploy $pkgname] : Menerapkan paket pkgname , yang berarti bahwa dengan menggantinya dengan garuda-bash-settings , seseorang akan menerapkan garuda-bash-settings .

Setelah salah satu kombinasi tersebut terdeteksi, penerapan dimulai setelah beberapa pemeriksaan berhasil diselesaikan. Log penerapan sebelumnya dapat diperiksa melalui bagian Saluran Pipa.

Benjolan otomatis

Repositori ini menyediakan jalur pipa setiap setengah jam yang memperbarui semua PKGBUILD ke versi terbarunya jika sumbernya berada di repositori lain , berdasarkan tag terbaru yang tersedia. Kemudian melanjutkan untuk memperbarui checksum dan mendorong perubahan kembali ke cabang utama. Penerapan baru secara otomatis dipicu dengan menambahkan [deploy *] ke pesan penerapan. Artinya, cukup dengan memasukkan tag baru untuk memicu penerapan versi paket baru untuk paket-paket ini. Pemberitahuan penting:

• Ini tidak berlaku untuk paket yang semua filenya ada di repositori ini
• Tag tidak boleh diawali dengan v
• Informasi yang diperlukan tentang sumber paket disediakan melalui file SOURCES. Setiap baris mengikuti skema $url $pkgname $project_id . Yang terakhir digunakan untuk mengambil tag terbaru melalui GitLab API dan dapat ditemukan di halaman pengaturan umum repositori.

Proses terakhir dari pekerjaan ini dapat diperiksa dengan menelusuri bagian saluran pipa, setiap saluran pipa dengan lencana terjadwal dijalankan oleh pengatur waktu. Selain itu, alur dapat dipicu secara manual dengan menelusuri bagian jadwal alur dan menekan run pipeline schedule .

Memperbarui versi secara manual

Untuk beberapa PKGUILD, seperti garuda-fish-config , semua file berada di repositori ini. Saat memperbarui PKGBUILD, pastikan juga untuk memperbarui file .SRCINFO yang sesuai karena file ini digunakan untuk mengurai semua informasi terkait paket!

Menambahkan paket

Menambahkan paket semudah membuat folder baru dengan nama $pkgbase paket tersebut. Letakkan PKGBUILD dan semua file lain yang diperlukan di sini. Oleh karena itu, menambahkan paket AUR semudah mengkloning repo dan menghapus folder .git . CI mengandalkan file .SRCINFO untuk mengurai sebagian besar informasi, oleh karena itu, penting untuk selalu memperbaruinya jika ada paket yang dikelola sendiri. Terakhir, tambahkan folder .CI yang berisi konfigurasi dasar ( CI_PKGBUILD_SOURCE diperlukan jika paket eksternalnya, PKBUILD yang dikelola sendiri tidak memerlukannya), komit perubahan apa pun, dan dorong perubahan kembali ke cabang utama. Harap ikuti konvensi penerapan konvensional saat melakukannya (cz-cli dapat membantu dalam hal itu!). Ini berarti melakukan seperti:

• feat($pkgname): init
• fix($pkgname): fix xyz
• chore($pkgname): update PKGBUILD
• ci(config): update

Hal ini tidak hanya membantu memiliki riwayat penerapan yang seragam, tetapi juga memungkinkan pembuatan log perubahan secara otomatis.

Menghapus paket

Hal ini dapat dilakukan dengan menghapus folder yang berisi PKGBUILD paket. Pekerjaan pembersihan kemudian akan secara otomatis menghapus paket usang apa pun melalui proses pipeline on-commit . Ini juga akan mempertimbangkan paket terpisah apa pun yang mungkin dihasilkan oleh suatu paket. Mengganti nama folder juga dihitung sebagai menghapus paket.

Pipa on-commit

Setiap kali mendorong penerapan baru, pipeline CI akan melakukan tindakan berikut:

• Memeriksa kapan tag scheduled terakhir dibuat. Ini digunakan untuk menentukan paket mana yang perlu dijadwalkan.
• Ini mem-parsing setiap penerapan untuk string [deploy $foldername] , hanya menerima nilai valid yang berasal dari folder PKGBUILD yang ada. [deploy all] juga merupakan parameter yang valid. Salah mengeja $pkgname adalah kesalahan fatal di sini. Masalah apa pun harus diperbaiki dan didorong secara paksa.
• Kemudian, file yang diubah diurai. Ini juga termasuk paket yang dihapus. Setiap konten folder relevan yang diubah akan menyebabkan penyebaran paket dari paket yang sesuai.
• Tindakan terakhir adalah membuat parameter jadwal (menyerahkannya ke pekerjaan terjadwal melalui artefak) dan menghapus semua paket usang jika langkah sebelumnya terdeteksi.
• Jika semua tindakan ini berhasil, tag scheduled akan diperbarui, sehingga kita dapat merujuknya pada proses pipeline selanjutnya.

Saluran pipa sesuai jadwal

Setengah jam

Setiap setengah jam, pipeline sesuai jadwal akan melaksanakan beberapa tugas:

• Memperbarui templat CI dari repositori templat (jika ini diaktifkan melalui .ci/config )
• Periksa apakah tag terjadwal tidak ada atau terjadwal tidak mengarah ke HEAD (dalam hal ini batalkan misi!)
• Periksa apakah pohon kerja .state yang berisi status paket ada, jika ada, maka akan diatur. Jika tidak, ia akan membuatnya kembali dari awal (misalnya, dengan dorongan paksa)
• Periksa apakah komit terakhir sudah otomatis (berisi "tugas(paket): perbarui paket [lewati ci]"), jika ya, komit yang dihasilkan dari jadwal akan menimpanya untuk menjaga riwayat komit tetap bersih.
• Kumpulkan stempel waktu AUR paket untuk menentukan apakah PKGBUILD berubah
• Ulangi setiap paket yang valid dan lakukan tindakan berikut:
  • Baca file .CI/config untuk mendapatkan informasi tentang konfigurasi paket (misalnya, apakah akan mengelola repositori AUR, sumber PKGBUILD, dll.)
  • Perbarui PKGBUILD dalam kasus berikut:
    • CI_PKGBUILD_SOURCE disetel ke gitlab : Memperbarui PKGBUILD dari tag repositori GitLab
    • CI_PKGBUILD_SOURCE disetel ke aur : Memperbarui PKGBUILD dari repositori AUR, menarik repo git dan mengganti file yang ada dengan yang baru. Jika stempel waktu AUR tidak dapat dikumpulkan sebelumnya, pembaruan paket akan dilewati.
    • CI_PKGBUILD_SOURCE tidak disetel ke gitlab atau aur : mencoba memperbarui PKGBUILD dengan menarik repositori yang ditentukan dalam CI_PKGBUILD_SOURCE. Jika kloning tidak berhasil setelah 2 kali percobaan, proses pembaruan akan dilewati.
  • Jika CI_GIT_COMMIT disetel di variabel konfigurasi paket, penerapan terbaru dari URL git yang disetel di bagian source PKGBUILD akan diperbarui. Jika berbeda, jadwalkan pembuatannya.
  • Jika ada kait khusus ( .CI/update.sh di dalam direktori paket), kait tersebut akan dieksekusi - ini dapat digunakan untuk memperbarui PKGBUILD dengan skrip khusus.
  • Menulis variabel yang diperlukan kembali ke .CI/config (mis. Git hash)
• Perbarui PKGBUILD secara diam-diam jika terjadi perubahan kecil, buat PR untuk ditinjau jika terjadi pembaruan besar (dan hanya jika CI_HUMAN_REVIEW benar)
  • Pembaruan hanya dipertimbangkan jika diff benar-benar melaporkan perubahan antara folder PKGBUILD saat ini dan repo AUR PKGBUILD
  • Setiap perubahan yang dilakukan pada file sumber terdeteksi, namun hal ini tidak mendeteksi perubahan berbahaya pada sumber proyek upstream yang dibuat oleh paket
• Pohon kerja negara bagian diperbarui dengan informasi baru
• Parameter jadwal sedang dibuat dan diserahkan ke pekerjaan terjadwal melalui artefak
• Cabang-cabang yang sudah usang (mis. PR tinjauan gabungan) sedang dipangkas
• Tag terjadwal diperbarui lagi

Sehari-hari

Jadwal pipeline harian telah ditambahkan untuk paket spesifik yang menghasilkan pkgver secara dinamis. Untuk memanfaatkannya, setel CI_ON_TRIGGER=daily di dalam file .CI/config paket.

Penjadwalan manual

Menjadwalkan paket tanpa git melakukan

Paket dapat ditambahkan ke jadwal secara manual dengan membuka halaman eksekusi alur, memilih "Jalankan alur" dan menambahkan PACKAGES sebagai variabel dengan nama paket sebagai nilainya. Pipeline kemudian akan mengambil paket dan menjadwalkannya. PACKAGES juga dapat diatur ke all untuk menjadwalkan semua paket. Jika satu atau banyak paket dijadwalkan, maka harus mengikuti format pkgname1:pkgname2:pkgname3 .

Menjalankan saluran pipa terjadwal sesuai permintaan

Hal ini dapat dilakukan dengan membuka halaman eksekusi alur, memilih "Jalankan alur" (simbol putar). Tautan ke halaman alur akan disediakan, tempat log alur dapat diperoleh.

Menambahkan mengganggu

Letakkan file interferensi yang diperlukan di folder .CI dari folder PKGBUILD:

• prepare : Skrip yang dijalankan setelah chroot bangunan telah disiapkan. Ini dapat digunakan untuk mencari variabel lingkungan atau memodifikasi hal-hal lain sebelum kompilasi dimulai.
  • Jika ada sesuatu yang perlu diatur sebelum proses kompilasi sebenarnya, perintah dapat dimasukkan dengan memasukkan misalnya. $CAUR_PUSH 'source /etc/profile' . Demikian pula, konflik paket dapat diselesaikan, misalnya. sebagai berikut: $CAUR_PUSH 'yes | pacman -S nftables' (tanda kutip tunggal penting karena kita ingin variabel/pipa dievaluasi saat runtime tamu dan bukan saat mengganggu)
• interfere.patch : file patch yang dapat digunakan untuk memperbaiki beberapa file atau PKGBUILD jika diperlukan banyak perubahan. Semua perubahan perlu ditambahkan ke file ini.
• PKGBUILD.prepend : isi file ini ditambahkan ke awal PKGBUILD.
• PKGBUILD.append : isi file ini ditambahkan ke akhir PKGBUILD. Memperbaiki build() semudah menambahkan build() tetap ke dalam file ini. Ini dapat digunakan untuk semua jenis perbaikan. Jika sesuatu perlu ditambahkan ke array, ini semudah makedepend+=(somepackage) .
• on-failure.sh : Skrip yang dijalankan jika build gagal.
• on-success.sh : Skrip yang dijalankan jika build berhasil.

Menabrak pkgrel

Ini sekarang dilakukan dengan menambahkan variabel yang diperlukan CI_PACKAGE_BUMP ke .CI/config . Lihat di bawah untuk informasi lebih lanjut.

Pohon ketergantungan

CI membangun pohon ketergantungan secara otomatis. Mereka diteruskan ke manajer Chaotic sebagai artefak CI dan dibaca setiap kali perintah jadwal dijalankan. Tidak diperlukan intervensi manual.

.CI/config

File .CI/config di dalam setiap direktori paket berisi tanda tambahan untuk mengontrol pipeline dan membangun proses.

• CI_MANAGE_AUR : Dengan menyetel variabel ini ke true , CI akan memperbarui repositori AUR yang sesuai di akhir proses pipeline jika terjadi perubahan (menghilangkan file terkait CI)
• CI_PACKAGE_BUMP : Mengontrol lonjakan paket untuk semua paket yang CI_MANAGE_AUR tidak disetel ke true . Ini meningkatkan pkgrel sebesar 0.1 untuk setiap peningkatan +1 variabel ini.
• CI_PKGBUILD_SOURCE : Menetapkan sumber untuk semua file terkait PKGBUILD, yang digunakan untuk mengambil file yang diperbarui dari repositori jarak jauh. Nilai yang valid saat ini adalah:
  • gitlab : Menarik PKGBUILD dari tag repositori GitLab. Itu harus mengikuti format gitlab:$PROJECT_ID . ID dapat diperoleh dengan menelusuri bagian umum pengaturan repositori.
  • aur : Menarik PKGBUILD dari repositori AUR, menarik repo git dan mengganti file yang ada dengan yang baru.
• CI_ON_TRIGGER : Dapat diberikan jika pemicu jadwal khusus harus menjadwalkan paket yang sesuai. Ini dapat digunakan untuk menjadwalkan paket setiap hari, dengan mengatur nilainya menjadi daily . Karena ini memeriksa apakah "$TRIGGER == $CI_ON_TRIGGER", jadwal khusus apa pun dapat dibuat menggunakan jadwal pipa dan menyetel TRIGGER ke midnight , menambahkan jadwal yang sesuai dan menyetel CI_ON_TRIGGER untuk paket apa pun yang terpengaruh ke midnight .
• CI_REBUILD_TRIGGERS : Tambahkan paket yang diketahui menyebabkan pembangunan kembali variabel ini. Daftar repositori untuk melacak versi paket disediakan melalui parameter CI_LIB_DB repositori. Setiap versi paket di-hash dan dibuang ke .ci/lib.state . Setiap proses pipeline terjadwal membandingkan versi dengan memeriksa ketidakcocokan hash dan akan memasukkan setiap paket yang terpengaruh melalui CI_PACKAGE_BUMP .
• BUILDER_CACHE_SOURCES : Dapat disetel ke true jika sumber harus di-cache di antara build. Hal ini dapat berguna jika sumber lambat atau sumber tidak tersedia sepanjang waktu. Sumber akan dihapus secara otomatis setelah 1 bulan, hal ini penting jika paket dihapus atau sumber diubah.

Mengelola paket AUR

Paket AUR juga dapat dikelola melalui repositori ini secara otomatis menggunakan .CI_CONFIG . Artinya, setelah setiap pipeline terjadwal dan on-commit, repositori AUR akan diperbarui untuk mencerminkan perubahan yang dilakukan pada file folder PKGBUILD. File yang tidak relevan dengan pemeliharaan AUR (misalnya folder .CI ) akan dihilangkan. Pesan penerapan mencerminkan fakta bahwa penerapan dibuat oleh alur CI dan berisi tautan ke riwayat penerapan repositori sumber dan eksekusi alur yang memicu penerapan pembaruan.

Memperbarui skrip CI

Hal ini dilakukan secara otomatis melalui pipeline CI. Setelah perubahan terdeteksi pada repositori templat, semua file akan diperbarui ke versi saat ini.

Masalah dan kegagalan saluran pipa

Pipeline on-commit terakhir gagal

Hal ini dapat terjadi karena beberapa alasan, misalnya nama paket yang diberikan tidak valid. Hal ini menyebabkan tag scheduled tidak diperbarui. Dalam hal ini, jalur pipa sesuai jadwal tidak akan dapat berjalan. Pipeline on-commit terakhir perlu diperbaiki sebelum pipeline on-schedule dapat dijalankan kembali. Namun kegagalan pembangunan tidak diperhitungkan karena tag scheduled akan diperbarui segera setelah parameter penjadwalan dibuat. Pemaksaan untuk melakukan komitmen yang sudah diperbaiki secara aktif dianjurkan dalam kasus seperti ini, karena mendorong komitmen yang lain akan menyebabkan CI mengevaluasi komitmen sebelumnya yang terlewat, sehingga menyebabkan masalah yang sama muncul lagi dan melakukan bail out alih-alih melanjutkan secara diam-diam. Ini merupakan keputusan desain untuk mencegah kegagalan agar tidak terabaikan.

Menyetel ulang antrian build

Mungkin ada kasus yang jarang terjadi di mana pengaturan ulang antrean build diperlukan. Hal ini dapat dilakukan dengan mematikan instance Redis pusat, menghapus dump-nya, dan memulai ulang layanannya.

Manajer Kekacauan

Alat ini didistribusikan sebagai container Docker dan terdiri dari sepasang instance pengelola dan pembuat.

• Manajer: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• Pembuat: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • Yang ini berisi logika sebenarnya di balik pembuatan paket (lihat di sini) yang diketahui dari infra 3.0 seperti interfere.sh , database.sh dll.
  • Memilih paket yang akan dibuat dari instans Redis yang dikelola oleh instans manajer

Manajer digunakan oleh GitLab CI dalam pekerjaan schedule-package , menjadwalkan paket dengan menambahkannya ke antrian build. Pembuatnya dapat digunakan oleh mesin apa pun yang mampu menjalankan container. Ini akan memilih pekerjaan yang tersedia dari instance Redis pusat kami.

Pengaturan pengembangan

Repositori ini dilengkapi dengan serpihan NixOS, yang dapat digunakan untuk mengatur hal-hal yang diperlukan seperti kait dan pemeriksaan pra-komit, serta utilitas yang diperlukan, secara otomatis melalui direnv. Ini termasuk memeriksa PKGBUILD melalui shellcheck dan shfmt . Yang dibutuhkan adalah nix (manajer paket) dan direnv, setelah itu lingkungan dapat dimasuki dengan menjalankan direnv allow .