簡介

DFSG 是 Debian Free Software Guideline 的簡寫, 目的是給出指引, 讓想參與到 Debian 的開源人有方可尋, 原文請參考

新手入門

0. Repository 中不要放任何自動產生的東西
1. Debian 社群會從完全從 source code build 起
   • 以上兩點規則其實並未被一致的套用在所有 project 上, 尤其是 autoconf 及 automake 產生的結果
2. 請加上 build 說明
3. 有些項目下會放置不完整的 /debian 目錄, 建議不要打包到發佈出來的 tarball, 會跟 Debian 社區最終做出的成果沖突
4. 請勿將相依的 library 放入. 維護一個你項目要用到的私有版本更是不建議, 往 upstream push 通常是最佳的選擇
5. 能提供 test case 最好, 在相依 library 更新時可以確保 build 出結果的可用性
6. 請將項目打包為 tar.{gz,bz2,lzma,xz} 的格式, 目前 Debian 只支持這些種類

授權

0. 避免創造自己的 license
1. 建議讓同一項目中的檔案都使用相同 license
2. 每個檔案開頭要帶上 license 資訊
3. 版權持有人的及聯絡方式 (如 e-mail) 尤其重要, 可放在檔案開頭, 或是集中放置於 AUTHORS 檔案中
4. DFSG 兼容的 license 資訊可參考這頁
5. License 請個別放置於項目的根
   • 多 license 的情況放置於各自獨立的檔案, 以 COPYING 條列
   • 單 license 的情況直接將 license 內容放置於 COPYING 檔中
6. 有任何變更請即時更新

發佈及版本管理

0. 發佈時請提供可供下載的 tarball
1. 請保持各發佈 tarball 與版本的穩定對應關係
2. 發佈時請確認版本號被遞增了
3. 有需要時大膽的變更版本號, 不管你的變動多微小或不起眼

源代碼打包

0. autotools 的項目請以 make distcheck 驗証並產生 tarball
1. 使用其他的 build 工具的話, 請用上它們類似於 make distcheck 的相應機制
2. 請為你的 tarball 加上 GPG sign
   • https://wiki.debian.org/Keysigning
   • https://wiki.debian.org/Keysigning/Coordination
   • https://help.riseup.net/en/security/message-security/openpgp/best-practices

路徑

0. Debian 的路徑規則請參考這頁
1. 請提供機制能在安裝時調整路徑, 比較建議的方式是以環境變量指定
2. 避免以 patch 的方式變更安裝位置
3. 請參考 XDB Base Directory Specification 為特定操作找到相應的路徑
4. 優先以 $HOME 定位 user home 目錄, 如果沒定羲的話才看 /etc/passwd

依賴管理

0. 寫明依賴的授權, 版本區間, 去哪 download, 項目主頁等
1. 依賴是否為可選的?
2. 避免使用未進到 distro 中的最新版本, 很花工的情況除外
3. 避免依賴於未發佈的版本
4. 避免依賴於以下兩種 patch
   • 針對特定 distro 打的
   • 個人未公開的
5. 如果要對依賴進行 patch, 請推送給上游, 並記錄下這個過程: patch 什麼時候送出的? 送到了哪個 mailing list 或 issue tracking system

測試

0. 能有測項針對 build 結果進行測試
1. 能有測項對安裝後的結果進行測試更好
2. Debian 社區會在 https://ci.debian.net/ 上固定執行這些測試

安全

0. 安全性是必須要注重的
1. 提供明確開放的安全問題回報渠道並快速反應
2. 為每個安全性問題取得一個 CVE ID, 並於 commit message, changelog, NEWS, 發佈時, 帶上這個 CVE ID
   • 具體 CVE ID 取得方式可參考 Kurt 的說明
3. 不要偷偷修掉安全問題, 這樣只會增加各發行版追蹤問題的難度, 想幹壤事的人還是事以找得出來的
4. 發佈安全修正時, 請提供 patch 內容, 或是 commit 的 link
5. 為舊但穩定的發行版本提供安全修正, 或是為這些發行版本的安全團隊提供協助
6. 有任何疑問可向 Debian Security Team 請求協助

庫

0. Shared libraries 要指定 SONAME
1. ABI 產生不兼容時, 請更新 SONAME
2. 盡量維持住 API 兼容性
3. 可配合 ABI Compliance Checker 進行確認
4. 如果 libraries 只用在自己的應用中的話就沒有必要公開
5. 以 hidden 做為 symbols 的默認可見度
6. Public API 以 whitelist 的方式 expose symbols

問題回報 & 追蹤

0. 建立並使用開放的問題追蹤系統
1. 建立並使用開放的版本控制系統
   • 請對外提供可讀權限

版本控制

0. 以 git 做為版本控制系統再好不過
1. Debian 大多數的打包管理都是配合 git 進行, 在 Fedora 則要求一定配合 git.
2. 版本控制系統有可能被攻破, 建議為 tag 加上 GPG sign, 指令如下
   git tag -s $YOUR_VERSION
3. 也可以為所有 tag 都加上 GPG sign