pkgbuilds

Garuda Linux PKGBUILD

此儲存庫包含目前駐留在其garuda儲存庫中的所有軟體包的 PKGBUILD。由於廣泛使用其 CI，它在 GitLab 上運行，並擁有唯讀的 GitHub 鏡像。

本回購協議的範圍

我們自己的所有 PKGBUILD 都包含在這裡。從歷史上看，它們被分成自己的儲存庫。為了更容易找到正確的 PKGBUILD，並允許更快地貢獻，我們最近將它​​們合併到這個新的儲存庫中。包括所有套件的 PKGBUILD，包括它們的設定檔（這適用於像garuda-fish-config這樣的較小檔案）。對於其中一些包，例如garuda-*-settings包，其內容仍然可以在其各自的存儲庫中找到。

發現任何問題嗎？

如果發生任何包裝問題或類似問題，請隨時透過我們的問題部分報告。您可以點擊此處建立一個新的。

如何貢獻？

我們非常感謝任何形式的貢獻！ ？為此，請按照下列步驟操作：

• 建立此儲存庫的一個分支。
• 在本地克隆你的 fork（簡短的 git 教程）。
• 將所需的變更新增至 PKGBUILD 或原始碼。
• 確保 shellcheck 和 shfmt 報告更改的檔案沒有問題
  • 需要先安裝所需的依賴項，例如。通過sudo pacman -S shfmt shellcheck
  • 透過 bash 執行lint.sh腳本bash ./.ci/lint.sh檢查程式碼
  • 透過bash ./ci/lint.sh apply
• 使用傳統的提交訊息進行提交，並將任何變更推送回您的分支。
  • commitizen 應用程式有助於建立合適的提交訊息。您可以透過 pip 安裝它，因為 Arch 儲存庫中目前沒有軟體包： pip install --user -U Commitizen 。然後在克隆的資料夾中運行cz commit繼續。
• 在我們的主儲存庫中建立一個新的合併請求。
• 檢查是否有任何管道運行失敗並應用最終建議。

然後我們將審查更改並最終合併它們。

處理某些包裝問題

已棄用和損壞的包

在某些情況下，已棄用的軟體包不再有任何用途，還會導致系統無法更新。這些可以透過將套件加入garuda-common-settings的conflicts()和garuda-update的 auto-pacman 來處理。結果是有問題的包由於衝突而自動刪除。

CI/建置工具

以下內容部分取自建置工具文檔，省略了與本儲存庫無關的資訊。如果您正在尋找安裝說明，請參閱完整的自述文件。

一般的

可以透過更改 PKGBUILD 目錄內的內容或將[deploy *]附加到提交訊息來自動觸發部署。與 PKGBUILD 檢查不同，這些檢查僅適用於main分支上的提交。支持的有：

• [deploy all] ：部署完整的garuda例程，表示此儲存庫中的所有 PKGBUILD。
• [deploy $pkgname] ：部署套件pkgname ，這意味著透過將其替換為garuda-bash-settings ，可以部署garuda-bash-settings 。

一旦偵測到任何這些組合，部署就會在成功完成一些檢查後開始。可以透過「管道」部分檢查過去部署的日誌。

自動顛簸

此儲存庫提供半小時一次的管道，如果其來源駐留在另一個儲存庫中，則根據最新的可用標籤，將所有 PKGBUILD 更新到最新版本。然後它繼續更新校驗和並將變更推送回主分支。透過將[deploy *]附加到提交訊息，會自動觸發新的部署。這意味著推送新標籤就足以觸發這些套件的新套件版本的部署。重要通知：

• 這不適用於所有文件都在此存儲庫中的包
• 標籤不得以v為前綴
• 有關包源的所需資訊透過 SOURCES 文件提供。每行都遵循方案$url $pkgname $project_id 。後者用於透過 GitLab API 檢索最新標籤，可以在儲存庫的常規設定頁面找到。

可以透過瀏覽管道部分來檢查該作業的最新運行情況，帶有計劃標記的每個管道都由計時器執行。此外，可以透過瀏覽管道計劃部分並點擊運行管道計劃來手動觸發管道。

手動更新版本

對於某些 PKGBUILD，例如garuda-fish-config ，所有檔案都駐留在此儲存庫中。更新 PKGBUILD 時，請確保同時更新對應的.SRCINFO文件，因為該文件用於解析所有包相關資訊！

添加包

新增包就像創建一個以包的$pkgbase命名的新資料夾一樣簡單。將 PKGBUILD 和所有其他必需的檔案放在這裡。因此，新增 AUR 套件就像克隆其儲存庫並刪除.git資料夾一樣簡單。 CI 依賴.SRCINFO檔案來解析大多數信息，因此，對於自我管理的包來說，將它們放置到位並保持最新非常重要。最後，新增一個包含基本配置的.CI資料夾（需要CI_PKGBUILD_SOURCE ，以防其外部包，自我管理的 PKBUILD 不需要它），提交任何更改，並將更改推送回主分支。這樣做時請遵循傳統的提交約定（cz-cli 可以幫助解決這個問題！）。這意味著提交如下：

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

這不僅有助於擁有統一的提交歷史記錄，還允許自動產生變更日誌。

刪除包

這可以透過刪除包含套件的 PKGBUILD 的資料夾來完成。然後，清理作業將透過on-commit管道運行自動刪除任何過時的套件。這也將考慮包可能生成的任何拆分包。重新命名資料夾也算作刪除包。

提交管道

每當推送新的提交時，CI 管道都會執行以下操作：

• 檢查最後一個scheduled標籤的建立時間。這用於確定需要安排哪些包。
• 它解析每個提交的[deploy $foldername]字串，僅接受從現有 PKGBUILD 資料夾派生的有效值。 [deploy all]也是一個有效參數。 $pkgname拼字錯誤是一個致命錯誤。任何問題都必須解決並強制推動。
• 然後，解析更改的檔案。這也包括已刪除的軟體包。任何變更的相關資料夾內容都會導致對應套件的套件部署。
• 最後的操作是建立計劃參數（透過工件將其移交給計劃作業）並刪除所有過時的包，以防檢測到較早的步驟。
• 如果所有這些操作都成功， scheduled標記就會更新，因此我們可以在以後的管道運行中引用它。

管道按計劃進行

半小時一班

每半小時，正點管道就會執行一些任務：

• 從範本儲存庫更新 CI 範本（如果透過.ci/config啟用）
• 檢查計劃標籤是否不存在或計劃未指向 HEAD（在這種情況下中止任務！）
• 檢查包含套件狀態的 .state 工作樹是否存在，如果存在，則設定它。否則，它會從頭開始重新建立它（例如，在強制推送時）
• 檢查最後一次提交是否是自動的（包含“chore（packages）：更新包[skip ci]”），如果是，則計劃產生的提交將覆蓋它以保持提交歷史記錄乾淨。
• 收集包的 AUR 時間戳記以確定 PKGBUILD 是否發生更改
• 循環遍歷每個有效包並執行以下操作：
  • 讀取.CI/config檔以取得有關套件配置的資訊（例如，是否管理 AUR 儲存庫、PKGBUILD 的來源等）
  • 在以下情況下更新 PKGBUILD：
    • CI_PKGBUILD_SOURCE 設定為gitlab ：從 GitLab 儲存庫標籤更新 PKGBUILD
    • CI_PKGBUILD_SOURCE 設定為aur ：從 AUR 儲存庫更新 PKGBUILD，拉入 git 儲存庫並用新檔案取代現有檔案。如果無法提前收集 AUR 時間戳，則會跳過套件更新。
    • CI_PKGBUILD_SOURCE 未設定為gitlab或aur ：嘗試透過拉取 CI_PKGBUILD_SOURCE 中指定的儲存庫來更新 PKGBUILD。如果兩次嘗試後克隆未成功，則會跳過更新過程。
  • 如果在套件設定變數中設定了 CI_GIT_COMMIT，則更新 PKGBUILD source部分中設定的 git URL 的最新提交。如果不同，請安排建造。
  • 如果存在自訂掛鉤（套件目錄內的.CI/update.sh ），它將被執行 - 這可用於使用自訂腳本更新 PKGBUILD。
  • 將所需的變數寫回.CI/config （例如 Git 雜湊）
• 如果發生較小的更改，則靜默更新 PKGBUILD；如果發生重大更新，則建立 PR 進行審查（並且僅當CI_HUMAN_REVIEW為 true 時）
  • 僅當 diff 實際報告目前 PKGBUILD 資料夾和 AUR PKGBUILD 儲存庫之間的變更時才考慮更新
  • 偵測到對原始檔案所做的任何更改，但這不會偵測到套件建置的上游專案來源中的惡意更改
• 狀態工作樹已更新為新訊息
• 計劃參數正在建置並透過工件移交給計劃作業
• 過時的分支（例如合併審查 PR）正在被修剪
• 預定標籤再次更新

日常的

已為動態生成其pkgver的特定軟體包添加了每日管道計劃。若要使用它，請在套件的.CI/config檔中設定CI_ON_TRIGGER=daily 。

手動調度

無需 git 提交即可調度包

可以透過前往管道運行頁面，選擇「運行管道」並將PACKAGES新增為變數並將套件名稱作為其值，將套件手動新增至計畫。然後管道將拾取包裹並安排它們。 PACKAGES也可以設定為all以安排所有套件。如果要安排一個或多個軟體包，則需要遵循pkgname1:pkgname2:pkgname3格式。

按需運行預定的管道

這可以透過前往管道運行頁面，選擇「運行管道」（播放符號）來完成。將提供管道頁面的鏈接，可以在其中獲取管道日誌。

添加干擾

將所需的干擾檔放入 PKGBUILD 資料夾的.CI資料夾：

• prepare ：在建立建置 chroot 後執行的腳本。它可用於在編譯開始之前取得環境變數或修改其他內容。
  • 如果在實際編譯過程之前需要設定某些內容，可以透過插入例如來推送命令。 $CAUR_PUSH 'source /etc/profile' 。同樣，可以解決包衝突，例如。如下： $CAUR_PUSH 'yes | pacman -S nftables' （單引號很重要，因為我們希望變數/管道在來賓運行時進行計算，而不是在幹擾時進行計算）
• interfere.patch ：一個補丁文件，可用於修復多個文件或 PKGBUILD（如果需要進行大量更改）。所有更改都需要添加到此文件中。
• PKGBUILD.prepend ：此檔案的內容被加入到 PKGBUILD 的開頭。
• PKGBUILD.append ：此檔案的內容新增至 PKGBUILD 的末端。修復build()就像將修復的build()添加到此檔案中一樣簡單。這可用於各種修復。如果需要將某些內容加入陣列中，這就像makedepend+=(somepackage)一樣簡單。
• on-failure.sh ：建置失敗時正在執行的腳本。
• on-success.sh ：建置成功時正在執行的腳本。

碰撞 pkgrel

現在透過將所需的變數CI_PACKAGE_BUMP新增至.CI/config來執行此操作。請參閱下文以了解更多資訊。

依賴樹

CI 自動建立依賴關係樹。它們作為 CI 工件傳遞給 Chaotic 管理器，並在執行計劃命令時讀取。無需人工幹預。

.CI/配置

每個包目錄中的.CI/config檔包含用於控制管道和建置程序的附加標誌。

• CI_MANAGE_AUR ：透過將此變數設為true ，如果發生更改，CI 將在管道運行結束時更新相應的 AUR 儲存庫（忽略 CI 相關檔案）
• CI_PACKAGE_BUMP ：控制所有未將CI_MANAGE_AUR設為true包的包碰撞。此變數每增加+1 ， pkgrel就會增加0.1 。
• CI_PKGBUILD_SOURCE ：設定所有 PKGBUILD 相關檔案的來源，用於從遠端儲存庫擷取更新的檔案。目前有效值為：
  • gitlab ：從 GitLab 儲存庫標籤中擷取 PKGBUILD。它需要遵循格式gitlab:$PROJECT_ID 。可以透過瀏覽儲存庫設定常規部分來取得該 ID。
  • aur ：從 AUR 儲存庫中提取 PKGBUILD，提取 git 儲存庫並用新檔案取代現有檔案。
• CI_ON_TRIGGER ：可在特殊調度觸發器應調度對應套件的情況下提供。透過將值設為daily ，可以用於每天安排包。由於這會檢查是否“$TRIGGER == $CI_ON_TRIGGER”，因此可以使用管道計劃並將TRIGGER設置為midnight來創建任何自定義計劃，添加擬合計劃並將任何受影響的包的CI_ON_TRIGGER設置為midnight 。
• CI_REBUILD_TRIGGERS ：新增已知會導致此變數重建的套件。透過儲存庫的CI_LIB_DB參數提供用於追蹤套件版本的儲存庫清單。每個包版本都經過哈希處理並轉儲到.ci/lib.state 。每個計劃的管道運行都會透過檢查雜湊不匹配來比較版本，並將透過CI_PACKAGE_BUMP碰撞每個受影響的套件。
• BUILDER_CACHE_SOURCES ：如果來源應該在建置之間緩存，則可以設定為true 。這在來源速度慢或來源並非始終可用的情況下非常有用。來源將在 1 個月後自動清除，這在軟體包被刪除或來源發生更改時非常重要。

管理 AUR 包

AUR 套件也可以使用.CI_CONFIG透過此儲存庫以自動化方式進行管理。這意味著在每個計劃和提交管道之後，AUR 儲存庫將更新以反映對 PKGBUILD 資料夾檔案所做的變更。與 AUR 維護無關的檔案（例如.CI資料夾）將被省略。提交訊息反映了提交是由 CI 管道創建的事實，並且包含指向來源儲存庫的提交歷史記錄和觸發更新提交的管道運行的連結。

更新 CI 的腳本

這是透過 CI 管道自動完成的。一旦在模板存儲庫上檢測到更改，所有文件都將更新到當前版本。

問題和管道故障

上次提交管道失敗

如果有多種原因，例如提供了無效的套件名稱，則可能會發生這種情況。這會導致scheduled標記無法更新。在這種情況下，按計劃進行的管道將無法運作。在按計劃管道可以再次運行之前，需要修復最後一個按提交管道。然而，建置失敗不會被考慮，因為一旦產生調度參數， scheduled標籤就會被更新。在這種情況下，積極鼓勵強制推送已修復的提交，因為推送另一個提交將導致 CI 評估它錯過的先前提交，從而導致再次注意到相同的問題並退出，而不是默默地繼續。這是為了防止忽視故障而做出的設計決策。

重置建置隊列

在極少數情況下，可能需要重置建置佇列。這可以透過關閉中央 Redis 實例、刪除其轉儲並重新啟動其服務來完成。

混亂的經理

該工具作為 Docker 容器分發，由一對管理器和建構器實例組成。

• 管理器： registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
• 生成器： registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
  • 這包含了從 infra 3.0 中已知的套件建構背後的實際邏輯（請參閱此處），例如interfere.sh 、 database.sh等。
  • 選擇要從管理員實例管理的 Redis 實例建置的套件

此管理器由 GitLab CI 在schedule-package作業中使用，透過將套件新增至建置佇列來調度套件。任何能夠運行容器的機器都可以使用該建構器。它將從我們的中央 Redis 實例中選擇可用的作業。

開發設定

此儲存庫具有 NixOS flake，可用於透過 direnv 自動設定所需的內容，例如預先提交掛鉤和檢查以及所需的實用程式。這包括透過shellcheck和shfmt檢查 PKGBUILD。需要的是nix （套件管理器）和 direnv，之後，可以透過執行direnv allow進入環境。