Table of Contents
這裡展示了 Debian 打包工作中針對非原生套件使用“3.0 (quilt)”格式進行打包所遵循基本規則的一個全域性性概覽。
![]() |
Note |
---|---|
為簡明起見,某些細節被有意跳過。請按需查閱對應命令的手冊頁,例如dpkg-source(1)、dpkg-buildpackage(1)、dpkg(1)、dpkg-deb(1)、deb(5),等等。 |
Debian 原始碼套件是一組用於構建 Debian 二進位制套件的輸入檔案,而非單個檔案。
Debian 二進位制套件是一個特殊的檔案檔案,其中包含了一系列可安裝的二進位制資料及與它們相關的資訊。
單個 Debian 原始碼套件可能根據 debian/control 檔案定義的內容產生多個 Debian 二進位制套件。
使用 “3.0 (quilt)”格式的非原生 Debian 套件是最普通的 Debian 原始碼套件格式。
![]() |
Note |
---|---|
有許多封裝指令碼可用。合理使用它們可以幫助您理順工作流程,但是請確保您能理解它們內部的基本工作原理。 |
建立 Debian 二進位制套件的 Debian 打包工作流涉及建立數個特定名稱的檔案(參見 Section 5.4, “套件名稱和版本”),與《Debian 政策手冊》的定義保持一致。
The oversimplified method for the Debian packaging workflow can be summarized in 10 steps as follows.
上游的原始碼壓縮包被複制(或符號連結)至一個特定的檔名 packagename_version.orig.tar.gz。
Debian 套件規範檔案將被新增至上游原始碼中,存放在 package-version/debian/ 目錄下。
debian/* 目錄下的必需技術說明檔案:
在 package-version/ 目錄中呼叫 debmake 命令將會提供這些配置檔案的一套模板。
The dpkg-buildpackage command (usually from its wrapper debuild or sbuild) is invoked in the package-version/ directory to make the Debian source and binary packages by invoking the debian/rules script.
使用 dpkg-source(1) 以“3.0 (quilt)”格式建立 Debian 原始碼套件
使用“debian/rules build”構建原始碼並安裝到 $(DESTDIR) 中
使用 dpkg-deb(1)、dpkg-genbuildinfo(1) 和 dpkg-genchanges(1) 建立 Debian 二進位制套件。
使用 lintian 命令檢查 Debian 套件的質量。(推薦)
遵守 ftp-master 的拒絕(rejection)指導方針。
Test building and confirming of the binary package goodness as above is the moral obligation as a diligent Debian developer but there is no physical barrier for people to skip such operations at this moment for the source-only upload.
Under some exceptional situation such as NEW uploads, uploads to the Debian archive may need to include Debian binary package files. For such situation, sign package_version-revision_arch.changes instead of 'package_version-revision’_*source.changes* in the step 9, and upload the set of the Debian source and binary package files in the step 10.
這裡,請將檔名中對應的部分使用下面的方式進行替換:
See also Source-only uploads.
![]() |
Tip |
---|---|
有很多種通過實踐摸索而得到的補丁管理方法和版本控制系統的使用策略與技巧。您沒有必要將它們全部用上。 |
![]() |
Tip |
---|---|
在“Debian 開發者參考”一文的 第 6 章 最佳打包實踐 部分有十分詳盡的相關文件。請讀一讀這些內容。 |
儘管 Debian 套件可以僅由編寫 debian/rules 指令碼而不使用 debhelper 套件來生成,其實這樣做是不切實際的。現代的 Debian“政策”對許多功能特性的實現做了要求,如應用適當的檔案許可權、使用合適的與硬體架構相關的軟體庫安裝路徑、安裝觸動指令碼的插入、除錯符號套件的生成、套件依賴資訊的生成、套件資訊檔案的生成、對時間戳調節以符合可重現構建的要求,等等。
Debhelper 套件提供了一套實用指令碼,用來簡化 Debian 打包工作流並減輕套件維護者的負擔。若能適當運用,它們可以幫助打包者自動地處理並實現 Debian”政策“所要求的功能。
現代化的 Debian 打包工作流可以組織成一個簡單的模組化工作流,如下所示:
您幾乎總是應當將 debhelper 列為您的軟體包的構建依賴之一。本文件在接下來的內容中也假設您正在使用一個版本足夠新的 debhelper 協助進行打包工作。
Let me oversimplify historical perspective of Debian packaging practices.
Debian
was started in 1990s when upstream packages were available from
public FTP sites such as Sunsite. In those early
days, Debian packaging used dpkg-source currently known as "Format:
1.0
":
In order to address issues of old dpkg-source "Format:
1.0
", new dpkg-source "Format: 3.0 (quilt)
" was
invented around 2008:
Format:
3.0 (quilt)
" to manage topic patches and made Debian packages
while keeping files outside of debian/
directory
untouched.
gbp-buildpackage
(1)
style.
gbp-buildpackage
(1) workflow records the exact same
content of the upstream tarball to VCS for source files outside of
debian/
directory (= patch-unapplied).
The use of Git repositories to distribute upstream packages with signed tags (supported feature since 2011) became very popular.
gbp-buildpackage
(1) workflow to
record changes to VCS was cumbersome for some Debian developers and
dgit
(1) was invented in 2013.
dgit-maint-debrebase
(7) and
dgit-maint-merge
(7) workflows to record changes to VCS
are gaining popularity among these Debian developers.
dgit-maint-debrebase
(7)
and git-maint-merge
(7) are modified upstream source files
(= patch-applied).
dgit-maint-debrebase
(7) and
git-maint-merge
(7) workflows still use dpkg-source
"Format: 3.0 (quilt)
".
Debian also enforced the source-only upload when developing Debian/11 Bullseye (released in 2021).
In this tutorial, mostly simple tarball based dpkg-source "Format:
3.0 (quilt)
" examples are presented as an introductory purpose.
Please assess these VCS usage approaches by yourself later to decide which one to deploy as your preferred one.
Please also read Notes on Debian by Russ Allbery which have best practices such as Using Git for Debian Packaging.
Please look around to understand how Debian packaging practices are evolving and follow the current general trends if possible.
DEP - Debian Enhancement Proposals
Debian git packaging maintainer branch formats and workflows
dgit
tool providers.
You can also search entire Debian source code by yourself, too.
Debian Sources — code search tool
如果所取得上游原始碼的形式為 hello-0.9.12.tar.gz,您可以將 hello 作為上游原始碼名稱,並將 0.9.12 作為上游版本號。
debmake 的目的是為套件維護者提供開始工作的模板檔案。註釋行以 # 開始,其中包含一些教材文字。您在將套件上傳至 Debian 倉庫之前必須刪除或者修改這樣的註釋行。
許可證資訊的提取和賦值過程應用了大量啟發式操作,因此在某些情況下可能不會正常工作。強烈建議您搭配使用其它工具,例如來自 devscripts 套件的 licensecheck 工具,以配合 debmake 的使用。
組成 Debian 套件名稱的字元選取存在一定的限制。最明顯的限制應當是套件名稱中禁止出現大寫字母。這裡給出正則表示式形式的規則總結:
請在《Debian 政策手冊》的 第 5 章 - Control 檔案及其欄位 一節中檢視其精確定義。
debmake 所假設的打包情景是相對簡單的。因此,所有與直譯器相關的程式都會預設為“Architecture: all”的情況。當然,這個假設並非總是成立。
您必須為 Debian 打包工作適當地調整套件名稱和上游版本號。
為了能有效地使用一些流行的工具(如 aptitude)管理套件名稱和版本資訊,最好能將套件名稱保持在 30 字元以下;版本號和修訂號加起來最好能不超過 14 個字元。[10]
為了避免命名衝突,對使用者可見的二進位制套件名稱不應選擇任何常用的單詞。
如果上游沒有使用像 2.30.32 這樣正常的版本編號方案,而是使用了諸如 11Apr29 這樣包含日期、某些代號或者一個版本控制系統雜湊值等字串作為版本號的一部分的話,請在上游版本號中將這些部分移除。這些資訊可以稍後在 debian/changelog 檔案中進行記錄。如果您需要為軟體設計一個版本字符串,可以使用 YYYYMMDD 格式,如 20110429 的字串作為上游版本號。這樣能保證 dpkg 命令在升級時能正確地確定版本的先後關係。如果您想要確保萬一上游在未來重新採納正常版本編號方案,例如 0.1 時能夠做到順暢地遷移,可以另行使用 0~YYMMDD 的格式,如 0~110429 作為上游版本號。
版本字串可以按如下的方式使用 dpkg 命令進行比較。
$ dpkg --compare-versions ver1 op ver2
版本比較的規則可以歸納如下:
對於某些字元,如句點(.)、加號(+)和波浪號(~),有如下的特殊規則。
0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0
有一個稍需注意的情況,即當上游將 hello-0.9.12-ReleaseCandidate-99.tar.gz 這樣的版本當作預釋出版本,而將 hello-0.9.12.tar.gz 作為正式版本時。為了確保 Debian 套件升級能夠順暢進行,您應當修改版本號命名,如將上游原始碼壓縮包重新命名為 hello-0.9.12~rc99.tar.gz。
使用“3.0 (quilt)”格式的非原生 Debian 套件是最常見最標準的 Debian 原始碼套件格式。根據 dpkg-source(1) 的描述,此時的 debian/source/format 檔案應當包含“3.0 (quilt) 的文字內容。上述的工作流和接下來給出的打包範例都使用了這種格式。
而原生 Debian 套件是較罕見的一種 Debian 套件格式。它通常只用於打包僅對 Debian 專案有價值、有意義的軟體。因此,該格式的使用通常不被提倡。
![]() |
Caution |
---|---|
在上游 tarball 原始碼壓縮包無法使用其正確名稱 package_version.orig.tar.gz 被 dpkg-buildpackage 取得到的時候,會出現意外地構建了原生 Debian 套件的情況。這是新手常見的一個錯誤,通常是因構建中錯誤地在符號連結名稱中使用了“-”字元而非正確的“_”字元。[譯註:此處仍然假設打包的場景是已經取得或形成了名為 package-version.tar.gz 的上游原始碼 tarball。Debian 的打包工作很大程度上是以上游原始碼 tarball 作為基礎的,這一點須時刻牢記在心。] |
原生 Debian 套件不對 上游程式碼 和 Debian 的修改 進行區分,僅包含以下內容:
如果您需要手動建立原生 Debian 套件,可以使用 dpkg-source(1) 工具以“3.0 (native)”格式進行建立。
![]() |
Tip |
---|---|
Some people promote packaging even programs that have been written only for Debian in the non-native package format. The required tarball without debian/* files needs to be manually generated in advance before the standard workflow in Section 5.1, “打包工作流”. [11] They claim that the use of non-native package format eases communication with the downstream distributions. |
![]() |
Tip |
---|---|
如果使用原生套件格式,沒有必要事先建立 tarball 壓縮包。要建立一個原生 Debian 套件,應當將 debian/source/format 檔案的內容設定為“3.0 (native)”,適當編寫 debian/changelog 文件使得版本號中不包含 Debian 修訂號(例如,1.0 而非 1.0-1),最後在原始碼樹中調用“dpkg-source -b .”命令。這樣做便可以自動生成包含原始碼的 tarball。 |
debian/rules 指令碼是用於實際構建 Debian 套件的可執行指令碼。
debian/rules 指令碼重新封裝了上游的構建系統(參見 Section 5.18, “上游構建系統”)以達到將檔案安裝至 $(DESTDIR)並將生成的檔案存入各個 deb 格式檔案中的目的。
$(DESTDIR) 路徑具體值依賴於構建的型別。
由 debhelper 套件提供的 dh 命令與一些相關的套件共同工作,作為典型的上游構建系統的一層封裝,同時它支援所有 Debian 政策(Debian Policy)規定必須在 debian/rules 實現的目標(target),以此提供一個統一的查詢介面。
![]() |
Note |
---|---|
對使用了 debhelper“compat >=9”的情況,dh 命令將在編譯引數未事先設定的情況下根據 dpkg-buildflags 命令返回的值設定並匯出各個編譯引數(如 CFLAGS、CXXFLAGS、FFLAGS、CPPFLAGS 和 LDFLAGS)。(dh 命令將呼叫在 Debian::Debhelper::Dh_Lib 模組中定義的 set_buildflags。) |
受益於 dh 命令對構建目標的抽象化 [12],一個符合 Debian 政策而支援所有必需目標(target)的 debian/rules 檔案可以簡單地寫成如下形式[13]:
簡單的 debian/rules:.
#!/usr/bin/make -f #export DH_VERBOSE = 1 %: dh $@
從本質上來看,這裡的 dh 命令的作用是作為一個序列化工具,在合適的時候呼叫所有所需的 dh_* 命令。
![]() |
Tip |
---|---|
設定“export DH_VERBOSE = 1”會輸出構建系統中每一條會修改檔案內容的命令。它同時會在某些構建系統中啟用詳細輸出構建日誌的選項。 |
通過新增合適的 override_dh_* 目標(target)並編寫對應的規則,可以實現對 debian/rules 指令碼的靈活定製。
如果需要在 dh 命令呼叫某些特定的 dh_foo 命令時採取某些特別的操作,則任何自動執行的操作均可以被 debian/rules 中額外新增的 override_dh_foo 這樣的 Makefile 目標所覆寫。
構建的過程可以使用某些上游提供的介面進行定製化,如使用傳遞給標準的原始碼構建系統的引數。這些構建系統包括但不限於:
在這種情況下,您應該新增一個 override_dh_auto_build 目標並在其中執行“dh_auto_build -- 設定引數” 的命令。這樣可以在 dh_auto_build 預設傳遞的引數之後確保將使用者給出的 設定引數 繼續傳遞給那些構建系統。
![]() |
Tip |
---|---|
如果上文提到的構建系統命令已知得到了 dh_auto_build 命令的支援的話,請避免直接呼叫這些命令(而讓 dh_auto_build 自動處理)。 |
debmake 命令所建立的初始模版檔案除了應用了上文提到的簡單 debian/rules 檔案的優點外,同時為後續可能涉及的套件強化等情景添加了一些額外的定製選項。您需要先了解整個構建系統背後的工作原理(參見 Section 5.18, “上游構建系統”),之後才能收放自如地定製套件來處理某些非常規的工作情況。
某些對設定 debian/rules 有用的變數定義可以在 /usr/share/dpkg/ 目錄下的檔案中找到。比較重要的包括:
如果您希望在 debian/rules 中使用其中的某些變數,您可以將相關的程式碼複製到 debian/rules 檔案中,或是重寫一份簡單的替代實現。總而言之請保持 debian/rules 檔案儘量簡單。
例如,您按如下的方法在 debian/rules 檔案中新增內容,從而為 linux-any 目標架構添加額外的 CONFIGURE_FLAGS:
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) ... ifeq ($(DEB_HOST_ARCH_OS),linux) CONFIGURE_FLAGS += --enable-wayland endif
![]() |
Tip |
---|---|
歷史上對於 debhelper 相容等級小於等於 8 的情況下,在 debian/rules 檔案中包含 buildflags.mk 檔案是很有用的,它可以合適地設定一些構建標誌,如 CPPFLAGS、CFLAGS、LDFLAGS 等,同時保證對特定選項,如 DEB_CFLAGS_MAINT_APPEND 和 DEB_BUILD_MAINT_OPTIONS 的合適處理。現在您應當使用的 debhelper 相容等級大於等於 9,故如無特殊原因,請不要繼續包含 buildflags.mk,請交由 dh 命令來處理和設定這些構建標誌。 |
參見 Section 5.22, “多體系架構”、dpkg-architecture(1) 和 dpkg-buildflags(1)。
為了做到套件可重現的構建,這裡給出一些相關的建議。
閱讀可重現構建瞭解更多資訊。
由 dpkg-genbuildinfo(1) 生成的控制檔案 source-name_source-version_arch.buildinfo 記錄了構建環境資訊。參見 deb-buildinfo(5)
debian/control 檔案包含了由空行分隔的數塊參數資料。每塊元資料按照如下的順序定義了下面這些內容:
See Chapter 5 - Control files and their fields of the “Debian Policy Manual” for the definition of each meta data.
![]() |
Note |
---|---|
The debmake command sets the debian/control file with “Build-Depends: debhelper-compat (= 13)” to set the debhelper compatibility level. |
![]() |
Tip |
---|---|
If an existing package has lower than debhelper compatibility level 9, probably it’s time to update its packaging. |
對行為良好的構建系統來說,對 Debian 二進位制包的拆分可以由如下方式實現。
請檢視本指南中相關的例子:
debmake 命令的 -b 選項提供了一個符合直覺又靈活的功能,可以用來建立 debian/control 的初始模板檔案,其中可以定義多個 Debian 二進位制套件,每節中含有如下欄位:
debmake 命令也會在每個適當的依賴欄位中設置合適的變數替換佔位符(substvars)。
我們在這裡直接引用 debmake 手冊頁中的相關一部分內容。
設定二進位制套件的指定型別內容,使用一個用逗號分隔的二進位制套件名:型別成對列表;例如,使用完整形式“foo:bin,foo-doc:doc,libfoo1:lib,libfoo-dev:dev”或者使用短形式,“-doc,libfoo1,libfoo-dev”。
這裡,二進位制套件是二進位制套件名稱,可選的類型應當從下面的型別值中進行選取:
括號內成對的值,例如(any,foreign),是套件的架構和多架構(Multi-Arch)特性的值,它們將設定在 debian/control 檔案中。
大多數情況下,debmake 命令可以有效地從二進位制套件的名稱猜測出正確的型別。如果型別的值並不明顯,程式將回退到將型別設定為bin。例如,libfoo 設定型別為 lib,而 font-bar 會令程式設定型別為 data,……
如果原始碼樹的內容和型別的設定不一致,debmake 命令會發出警告。
對於下面這樣的上游原始碼範例,我們在這裡給出使用 debmake 處理時一些典型的 multiarch 套件拆分的場景和做法:
二進位制套件 | 型別 | Architecture: | Multi-Arch: | 套件內容 |
---|---|---|---|---|
lib foo1 |
lib * |
any |
same |
共享程式庫,可共同安裝 |
lib foo -dev |
dev * |
any |
same |
共享程式庫標頭檔案及相關開發檔案,可共同安裝 |
lib foo -tools |
bin * |
any |
foreign |
執行時支援程式,不可共同安裝 |
lib foo -doc |
doc * |
all |
foreign |
共享程式庫文件 |
bar |
bin * |
any |
foreign |
編譯好的程式檔案,不可共同安裝 |
bar -doc |
doc * |
all |
foreign |
程式的配套文件檔案 |
baz |
script |
all |
foreign |
解釋型程式檔案 |
我們考慮 libfoo 這個程式庫的上游 tarball 原始碼壓縮包的名字從 libfoo-7.0.tar.gz 更新為了 libfoo-8.0.tar.gz,同時帶有一次 SONAME 大版本的跳躍(並因此影響了其它套件)。
程式庫的二進位制套件將必須從 libfoo7 重新命名為 libfoo8 以保持使用 unstable 套件的系統上所有依賴該程式庫的套件在上傳了基於 libfoo-8.0.tar.gz 的新程式庫後仍然能夠正常運行。
![]() |
Warning |
---|---|
如果這個二進位制程式庫套件沒有得到更名,許多使用 unstable 套件的系統上的各個依賴該程式庫的套件會在新的程式庫包上傳後立刻破損,即便立刻請求進行 binNMU 上傳也無法避免這個問題。由於種種原因,binNMU 不可能在上傳後立刻開始進行,故無法緩解問題。 |
-dev 套件必須遵循以下命名規則:
使用不帶版本號的 -dev 套件名稱:libfoo-dev
使用帶版本的 -dev 套件名稱:libfoo7-dev 和 libfoo8-dev
兩個版本的程式庫原始碼套件可同時出現在發行版倉庫中。
![]() |
Tip |
---|---|
如果包內資料檔案編碼方案有所變化(如,從 latin1 變為 utf-8),該場景應比照 API 變化做類似的考慮與處理。 |
debian/control 也定義了套件的依賴關系,其中變數替換機制(substvar)的功能可以用來將套件維護者從追蹤(大多數簡單的)套件依賴的重複勞動中解放出來。請參見 deb-substvars(5)。
debmake 命令支援下列變數替換指令:
對共享連結程式庫來說,所需要的依賴程式庫是由執行“objdump -p /path/to/program | grep NEEDED”這樣的命令來得到的,由 shlib 佔位符進行變數替換。
對於 Python 和其它直譯器來說,所需的模組通常由對包含類似“import”、“use”、“require”等等關鍵字的行進行解析,並會體現在各自對應的變數替換佔位符所在位置上。
對其它沒有部署屬於自己範疇內的變數替換機制的情況,misc 變數替換佔位符通常用來覆蓋對應的依賴替換需求。
對 POSIX shell 程式來說,並沒有簡單的辦法來驗證其依賴關係,substvar 的變數替換也無法自動得出它們的依賴。
對使用動態載入機制,包括 GObject introspection 機制的程式庫和模組來說,現在沒有簡單的方法可以檢查依賴關係,變數替換機制也無法自動推匯出所需的依賴。
一個 binNMU(二進位制非維護者上傳) 是為程式庫遷移或其它目的所作的非維護者套件上傳。在一次 binNMU 上傳中,只有“Architecture: any”的套件會被重構建,其版本號會在末尾附加一個編號(例如,原來版本為 2.3.4-3,新上傳的包版本會變成 2.3.4-3+b1)。所有“Architecture: all”的包將不會重新構建。
來自同一個原始碼套件的各個二進位制包如果在 debian/control 檔案中有互相的依賴關係,這些二進位制包通常情況下應當對 binNMU 是安全的(即,進行 binNMU 不會破壞依賴關係)。然而,在“Architecture: any”和“Architecture: all”的套件同時由同一原始碼套件產出,且互相之間有依賴關係時,需要小心對待所依賴的版本,必要時應做出調整。
“Architecture: any”的套件依賴於“Architecture: any”foo 套件
“Architecture: any”的套件依賴於“Architecture: all”bar 套件
“Architecture: all”的套件依賴於“Architecture: any”baz 套件
debian/changelog 檔案記錄了 Debian 軟體包的歷史並在其第一行定義了上游套件的版本和 Debian 修訂版本。所有改變的內容應當以明確、正式而簡明的語言風格進行記錄。
即便您在自己獨立進行套件上傳,您也必須記錄所有較重要、使用者可見的變更,例如:
如果您需要他人協助您進行上傳,您應當更詳盡地記錄變更內容,包括所有打包相關的變動,從而方便他人對您的套件進行審查。
debmake 命令會建立初始的模板檔案,其中帶有上游套件版本和 Debian 打包修訂編號。發行版部分被設定為 UNRELEASED 以避免半成品不小心被上傳進入 Debian 倉庫。
通常使用 debchange 命令(它具有一個別名,即 dch)對其進行編輯。
![]() |
Tip |
---|---|
您也可以手動使用任何文字編輯器修改 debian/changelog 檔案,只要您能夠遵循 debchange 命令所使用的特定文字排版格式即可。 |
![]() |
Tip |
---|---|
debian/changelog 檔案使用的日期字串可以使用“LC_ALL=C date -R”命令手動生成。 |
該檔案將由 dh_installchangelogs 命令安裝到 /usr/share/doc/binarypackage 目錄,檔名為 changelog.Debian.gz。
上游的變更日誌則會安裝至 /usr/share/doc/binarypackage 目錄中,檔名為 changelog.gz。
上游的變更日誌是由 dh_installchangelogs 程式自動進行搜尋和處理的;它會使用大小寫不敏感的搜尋方式尋找上游程式碼中特定名稱的檔案,如 changelog、changes、changelog.txt、changes.txt、history、history.txt 或 changelog.md。除了根目錄,程式還會在 doc/ 目錄和 docs/ 目錄內進行搜尋。
當您完成了主要打包工作並驗證了其質量之後,請考慮執行“dch -r”命令並將最終完成的 debian/changelog 檔案中發行版(distribution)部分進行設定,通常該欄位應當使用 unstable。[14] 如果您的打包是一次向後移植(backports)、是安全更新或是對長期支援版的上傳等等其它情況,請使用相應合適的發行版名稱。
Debian 以十分嚴肅的態度對待版權和許可證資訊。《Debian 政策手冊》強制規定軟體包的 debian/copyright 檔案中需要提供相關資訊的摘要。
您應當按照 機器可解析的 debian/copyright 檔案(DEP-5)對其進行排版。
![]() |
Caution |
---|---|
這裡的 debian/copyright 檔案中描述的許可證資訊匹配資訊應當合適地進行排序,以確保越寬泛的檔案匹配越靠前。請參見 Section 6.4, “debmake -k”。 |
debmake 命令會以掃描整個原始碼樹的方式建立初步的、相容 DEP-5 的模板檔案。它會內部呼叫許可證檢查工具來對許可證文字進行分類。[15]
除非明確指定(有些嚴格過頭的) -P 選項,debmake 命令會為了實用性而跳過對自動生成的檔案的檢查與報告,預設它們採用寬鬆的許可證。
![]() |
Note |
---|---|
如果您發現了這個許可證檢查工具存在一些問題,請對 debmake 套件提交缺陷報告並提供包含出現問題的許可證和版權資訊在內的相關文字內容。 |
![]() |
Note |
---|---|
debmake 命令專注於在建立 debian/copyright 模板時聚合相同的授權和許可證資訊並收錄其詳細內容。為了在有限的時間內儘可能完成工作,工具將只會提取檔案中第一塊看起來像授權文字或許可證宣告的部分。因此,生成的許可證資訊可能並不完美。請同時考慮使用其它工具,如 licensecheck 輔助進行檢查。 |
![]() |
Tip |
---|---|
我們強烈推薦您使用 licensecheck(1) 命令再次檢查原始碼許可證的狀態,並在有必要的情況下進行人工程式碼審查。 |
在構建過程開始之前,debian/patches/ 目錄內的 -p1 等級的補丁將會按照在 debian/patches/series 檔案中指定的順序依次應用於上游程式碼樹中。
![]() |
Note |
---|---|
原生 Debian 套件(參見 Section 5.5, “原生 Debian 套件”)將不使用這些檔案。 |
要準備這一系列 -p1 等級的補丁,有幾種不同的方式可供您選擇。
diff 命令
原始但萬能的方法
dquilt 命令
“dpkg-source --commit”命令
由 dpkg-buildpackage 自動生成補丁
The gbp pq command
The git-dpm command
無論這些補丁的來源如何,都建議使用兼容於 DEP-3 的頭部資訊對其進行標記。
![]() |
Tip |
---|---|
dgit 套件提供了另外一套直接使用 git 集成操作 Debian 套件倉庫的工具。 |
“dpkg-source -x” 命令可以對 Debian 原始碼包進行解壓縮。
該命令通常會將 debian/patches/ 目錄內的補丁應用在原始碼樹中,並將補丁狀態記錄在 .pc/ 目錄中。
如果您想保持原始碼樹不做修改(例如,為了在 Section 5.15, “在版本控制系統中進行記錄(標準)” 中繼續使用),請在命令列中使用 --skip-patches 選項。
在 dpkg-source 工具 1.16.1 版本之前,該工具還未提供 --commit 選項對應的功能,此時需要 quilt 命令(或者對它的封裝,dquilt 命令)來管理 debian/patches/ 目錄中的 -p1 等級的補丁。
在使用 dpkg-source 命令時,補丁應當能夠乾淨地進行應用。因此在補丁行數出現偏移或者其它情況出現時,您不能直接將舊補丁原封不動地複製到新版上游釋出對應打包版本的目錄中。
與此相對的是 dquilt 命令(參見 Section 3.4, “quilt”)對補丁的處理更加寬容。您可以呼叫 dquilt 命令對補丁進行正常化。
$ while dquilt push; do dquilt refresh ; done $ dquilt pop -a
使用 dpkg-source 命令比起使用 dquilt 命令來說存在一大優勢:dquilt 命令無法自動處理二進位制檔案出現變更的情況,而 dpkg-source 命令能夠探測出現內容變動的二進位制檔案,並將其列入 debian/source/include-binaries 檔案以便在 Debian 打包用壓縮包中將檔案囊括其中。
某些套件由 GPG 金鑰進行了簽名。
例如,GNU hello 可使用 HTTP 協議從 https://ftp.gnu.org/gnu/hello/ 下載。它含有以下檔案:
我們現在來選擇最新的版本套裝。
$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz ... $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz.sig ... $ gpg --verify hello-2.9.tar.gz.sig gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00 gpg: Can't check signature: public key not found
如果您從郵件列表獲知上游維護者所使用的 GPG 公鑰資訊,請將它作為 debian/upstream/signing-key.asc 檔案進行儲存。否則,請使用 hkp 公鑰伺服器並經由您的信任網進行驗證。
$ gpg --keyserver hkp://keys.gnupg.net --recv-key 80EE4A00 gpg: requesting key 80EE4A00 from hkp server keys.gnupg.net gpg: key 80EE4A00: public key "Reuben Thomas <rrt@sc3d.org>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 $ gpg --verify hello-2.9.tar.gz.sig gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00 gpg: Good signature from "Reuben Thomas <rrt@sc3d.org>" ... Primary key fingerprint: 9297 8852 A62F A5E2 85B2 A174 6808 9F73 80EE 4A00
![]() |
Tip |
---|---|
如果您的網路環境阻擋了對 HKP 11371 埠的連線,請考慮使用“hkp://keyserver.ubuntu.com:80”。 |
在確認金鑰身份 80EE4A00 值得信任之後,應當下載其公鑰並將其儲存在 debian/upstream/signing-key.asc 檔案中。
$ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.asc
之後,應相應地在 debian/watch 檔案中做如下的修改。
version=4 pgpsigurlmangle=s/$/.sig/ https://ftp.gnu.org/gnu/hello/ hello-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)
現在 uscan 命令會在掃描時自動使用 GPG 籤名驗證上游原始碼套件的真實性。
Debian 嚴肅地對待軟體自由,遵循 Debian 自由軟體指導方針(DFSG)。
在使用 uscan 命令來更新 Debian 打包所用程式碼時,上游原始碼套件(tarball)中不符合Debian 自由軟體指導方針(DFSG)的部分可以利用該工具簡單地進行移除。
執行 uscan 命令以下載新的上游原始碼套件(tarball)。
另外也可以新增一些可選的配置檔案並放入 debian/ 目錄。它們大多用於控制由 debhelper 套件提供的 dh_* 命令的行為,但也有一些檔案會影響 dpkg-source、lintian 和 gbp 這些命令。
![]() |
Tip |
---|---|
請檢查 debhelper(7) 的內容以瞭解當前可用的 dh_* 命令列表。 |
這些 debian/binarypackage.* 的檔案提供了設定檔案安裝路徑的強大功能。即使上游原始碼沒有構建系統,這個軟體依然可以利用這裡提到的這些文件來進行打包。請參考 Section 8.2, “無 Makefile(shell,命令列介面)” 的範例。
下面列表中出現的“-x[1234]”上標指示了 debmake -x 選項生成對應模板檔案所需要的最小值。請參考 debmake(1) 以瞭解詳情。
下面按照字母表順序列出一些值得注意的可選配置檔案。
列出需要安裝的 bash
補全指令碼。
需要在構建環境和使用者環境內均安裝 bash-completion
套件。
另請參考dh_bash-completion(1)。
列出(構建前)未被 dh_auto_clean 命令清理,且需要手工清理的檔案。
另請參考 dh_auto_clean(1) 和 dh_clean(1)。
Previously, this set the debhelper compatibility level.
Now, use Build-Depends: debhelper-compat (=
13)
in debian/control to specify the compatibility level.
另請參考 debhelper(8) 中“COMPATIBILITY LEVELS”一節。
No need for this file now since all files in the etc/ directory are conffiles for recent “compat >= 3”.
如果您正要打包的程式要求每個使用者都對 /etc 目錄下的配置檔案進行修改,可以採取兩種常見辦法使其不作為 conffile 配置檔案出現,避免 dpkg 命令處理套件時給出不必要的處理選項。
另請參考 dh_installdeb(1)。
安裝至 binarypackage 包內的 etc/cron/hourly/binarypackage 檔案。
另請參見 dh_installcron(1) 和 cron(8)。
安裝至 binarypackage 包內的 etc/cron/daily/binarypackage 檔案。
另請參見 dh_installcron(1) 和 cron(8)。
安裝至 binarypackage 包內的 etc/cron/weekly/binarypackage 檔案。
另請參見 dh_installcron(1) 和 cron(8)。
安裝至 binarypackage 包內的 etc/cron/monthly/binarypackage 檔案。
另請參見 dh_installcron(1) 和 cron(8)。
安裝至 binarypackage 包內的 etc/cron.d/binarypackage 檔案。
參見 dh_installcron(1)、cron(8) 和 crontab(5)。
若該檔案存在,它將被安裝至 binarypackage 包中的 etc/default/binarypackage 位置。
參見 dh_installinit(1)。
列出 binarypackage 包中要建立的目錄。
參見 dh_installdirs(1)。
通常情況下您並不需要這麼做,因為所有的 dh_install* 命令都會自動建立所需的目錄。請僅在遇到問題時考慮使用這一工具。
作為 binarypackage 包中的 doc-base 控制檔案進行安裝。
參見 dh_installdocs(1) 和 doc-base 套件提供的 Debian doc-base 手冊。
列出要安裝在 binarypackage 包中的文件檔案。
參見 dh_installdocs(1)。
安裝至 binarypackage 包中的 usr/lib/emacsen-common/packages/compat/binarypackage 檔案。
參見 dh_installemacsen(1)。
安裝至 binarypackage 包中的 usr/lib/emacsen-common/packages/install/binarypackage 檔案。
參見 dh_installemacsen(1)。
安裝至 binarypackage 包中的 usr/lib/emacsen-common/packages/remove/binarypackage 檔案。
參見 dh_installemacsen(1)。
安裝至 binarypackage 包中的 usr/lib/emacsen-common/packages/startup/binarypackage 檔案。
參見 dh_installemacsen(1)。
列出要安裝至 binarypackage 包中 usr/share/doc/binarypackage/examples/ 位置下的範例檔案或目錄。
參見 dh_installexamples(1)。
如果該檔案存在,它將作為 gbp 命令的配置檔案發揮作用。
參見 gbp.conf(5)、gbp(1) 和 git-buildpackage(1)。
列出要安裝至 binarypackage 包中的 info 檔案。
參見 dh_installinfo(1)。
安裝至 binarypackage 包中的 etc/init.d/binarypackage 檔案。
參見 dh_installinit(1)。
列出未被 dh_auto_install 命令安裝的其它應當安裝的檔案。
參見 dh_install(1) 和 dh_auto_install(1)。
這是 debmake 命令生成的版權宣告檔案示例,請用它們作為 debian/copyright 檔案的參考。
請在最終工作成果中刪除這些檔案。
列出要生成符號連結的原始檔和目標檔案對。每一對連結均應在單獨的一行中列出,源檔案和目標檔案之間使用空白字元分隔。
參見 dh_link(1)。
安裝至套件構建目錄的 usr/share/lintian/overrides/binarypackage 位置。該檔案用於消除 lintian 錯誤生成的診斷資訊。
參見 dh_lintian(1)、lintian(1) 和 Lintian 使用者手冊。
這些檔案是 debmake 命令生成的 man 手冊頁模板檔案。請將其重新命名為合適的檔名並更新其內容。
Debian 的政策要求套件為其包含的每個程式、工具和函式同時提供一份相關的手冊頁。手冊頁使用 nroff(1) 語法寫成。
如果您不熟悉如何編寫使用者手冊頁,請以 manpage.asciidoc 或 manpage.1 為起點。
列出要安裝的 man 手冊頁。
參見 dh_installman(1)。
tech-ctte #741573 決定“Debian 應該在合適的情況下使用 .desktop 檔案”。
安裝至 binarypackage 包中的 usr/share/menu/binarypackage Debian 選單文件。
參見 menufile(5) 以瞭解其格式。另請參見 dh_installmenu(1)。
安裝至 usr/share/doc/binarypackage/NEWS.Debian 檔案。
參見 dh_installchangelogs(1)。
這是 -p1 補丁檔案的集合,它們將在使用源程式碼構建之前應用在上游原始碼上。
參見 dpkg-source(1)、Section 3.4, “quilt” 和 Section 4.9, “第三步(備選):修改上游原始碼”。
debmake 預設不會生成補丁檔案。
這些維護者指令碼將安裝至套件的 DEBIAN 目錄下。
在這些指令碼中,#DEBHELPER# 記號將由其它 debhelper 命令進行處理,將其替換為相應的 shell 指令碼片段。
See dh_installdeb(1) and Chapter 6 - Package maintainer scripts and installation procedure in the “Debian Policy Manual”.
See also debconf-devel(7) and 3.9.1 Prompting in maintainer scripts in the “Debian Policy Manual”.
安裝至 debian/control 檔案列出的第一個二進位制套件中的 usr/share/doc/binarypackage/README.Debian 位置。
參見 dh_installdocs(1)。
該檔案提供了針對該 Debian 套件的資訊。
如果該檔案存在,它將被安裝到 binarypackage 包下面的 lib/systemd/system/binarypackage.service 位置。
參見 dh_systemd_enable(1)、dh_systemd_start(1) 和 dh_installinit(1)。
Debian 套件格式。
參見 dpkg-source(1) 的“原始碼套件格式”一節。
這些檔案不會最終被安裝,但 lintian 會對它們進行掃描以提供原始碼套件的 override 資訊。
另請參考 dh_lintian(1) 和 lintian(1)。
dpkg-source 命令使用此內容作為它的選項,比較重要的選項有:
該檔案不會包含在生成的原始碼套件中,僅對維護者在版本控制系統中維護套件有意義。
參見 dpkg-source(1) 中的“檔案格式”一節。
自由格式的文字,將被包含在自動生成補丁的頂部。
該檔案不會包含在生成的原始碼套件中,僅對維護者在版本控制系統中維護套件有意義。
+ 參見 dpkg-source(1) 的“檔案格式”一節。
這些符號檔案如果存在,將交由 dpkg-gensymbols 命令進行處理和安裝。
參見 dh_makeshlibs(1) 和 Section 5.20.1, “程式庫符號”。
安裝至 debian/control 檔案列出的第一個二進位制包中的 usr/share/doc/binarypackage/TODO.Debian 檔案。
參見 dh_installdocs(1)。
如果該檔案存在,它將被安裝至 binarypackage 包中的 usr/lib/tmpfiles.d/binarypackage.conf 檔案。
參見 dh_systemd_enable(1)、dh_systemd_start(1) 和 dh_installinit(1)。
如果該檔案存在,它將被安裝至套件構建目錄的 etc/init/package.conf 位置。(已棄用)
參見 dh_installinit(1) 和 Section 8.1, “挑選最好的模板”。
用於下載最新上游版本的 uscan 命令的控制檔案。
該控制檔案也可配置以使用其 GPG 簽名自動驗證上游 tarball 的真實性(參見 Section 5.11, “debian/upstream/signing-key.asc”)。
參見 Section 5.12, “debian/watch 和 DFSG” 和 uscan(1)。
這裡給出針對上面列表中資訊的一些額外提醒。
我們來重新歸納一下 Debian 打包定製化的相關內容。
所有對 Debian 套件進行定製化的資料都存在於 debian/ 目錄中。我們在Section 4.7, “第三步:編輯模板檔案”這裡給出了一個簡單的例子。通常情況下,定製化會涉及以下各個專案:
如果以上提到的手段仍然不足以製作滿足要求的 Debian 套件的話,對上游原始碼的修改應當使用 -p1 補丁檔案存放在打包原始碼樹 debian/patches/ 目錄下。這些補丁將按照 debian/patches/series 檔案所規定的順序在構建套件之前應用(參見 Section 5.10, “debian/patches/*”)。Section 4.9, “第三步(備選):修改上游原始碼” 這裡給出了一些簡單的例子。
您應當以引入最少修改的方式解決打包中出現的根本問題。所生成的套件應當考慮到未來的更新需求並有一定的健壯性。
![]() |
Note |
---|---|
如果補丁對上游有所幫助的話,也請將解決根本問題的補丁反饋給上游作者和維護者。 |
通常情況下,Debian 打包活動使用 Git 作為版本控制系統(VCS)進行記錄;通常會用到下列的分支。
master 分支
upstream 分支
![]() |
Tip |
---|---|
新增一個 .gitignore 檔案並將 .pc 檔案列入其中也是一個好主意。 |
![]() |
Tip |
---|---|
可以在 debian/source/local-options 檔案中新增 unapply-patches 和 abort-on-upstream-changes 這兩行以保持上游原始碼處於未修改狀態。 |
![]() |
Tip |
---|---|
您也可以使用除 upstream 分支以外其它名稱的分支追蹤上游版本控制資料以方便揀選補丁。 |
您也可以選擇不建立 -p1 等級的補丁。這時,您可以使用下列分支來記錄 Debian 打包活動。
master 分支
upstream 分支
如下在 debian/ 目錄下額外新增一些檔案即可達到目的。
$ tar -xvzf <package-version>.tar.gz $ ln -sf <package_version>.orig.tar.gz $ cd <package-version>/ ... hack...hack... $ echo "single-debian-patch" >> debian/source/local-options $ cat >debian/source/local-patch-header <<END This patch contains all the Debian-specific changes mixed together. To review them separately, please inspect the VCS history at https://git.debian.org/?=collab-maint/foo.git.
如此可讓 Debian 打包過程(dpkg-buildpackage、debuild 等)所呼叫的 dpkg-source 命令自動生成一個 -p1 等級的補丁檔案 debian/patches/debian-changes。
![]() |
Tip |
---|---|
這種做法可以應用在任何版本控制工具中。這麼做會把所有修改合併到同一個補丁檔案中而丟失其開發歷史,因此請務必保持版本控制系統的資料公開可見。 |
![]() |
Tip |
---|---|
debian/source/local-options 和 debian/source/local-patch-header 檔案只用於在版本控制系統中記錄資訊。它們不應包含在 Debian 原始碼套件中。 |
在某些情況下,直接使用自動生成的 Debian 原始碼套件會引入不必要的一些內容。
通常情況下,Section 3.5, “devscripts” 中設定的用於 dpkg-source 命令的 -i 和 -I 選項可以避免這些問題。這裡 -i 針對非原生套件而 -I 則針對原生套件。請參見 dpkg-source(1) 和“dpkg-source --help”的輸出。
以下幾種方法均可避免引入不必要的內容。
含有多餘檔案的問題可以使用“debian/rules clean”這個 Makefile 目標的呼叫來解決,只需在該目標內刪除檔案即可。它也能處理自動生成的檔案。
![]() |
Note |
---|---|
執行 dpkg-buildpackage 命令時,它會在“dpkg-source --build”命令之前被調用“debian/rules clean”目標,而“dpkg-source --build”命令會忽略被刪除的檔案。 |
含有多餘檔案的問題還可以使用版本控制系統修復;具體來說,可以在首次構建之前將原始碼樹提交到版本控制系統中。
您可以在第二次構建套件之前恢復最初的原始碼樹。例如:
$ git reset --hard $ git clean -dfx $ debuild
這裡工作的原理是 dpkg-source 命令會忽略原始碼樹中典型的版本控制系統相關的檔案,相關的設定可以在 Section 3.5, “devscripts” 的 DEBUILD_DPKG_BUILDPACKAGE_OPTS 設定中找到。
![]() |
Tip |
---|---|
如果原始碼樹未受版本控制系統管理,您可以在第一次構建之前執行“git init; git add -A .; git commit”來初始化。 |
這種做法僅適合非原生套件。
含有多餘檔案的問題可以使用在 debian/source/options 檔案中新增忽略資訊的方式解決,令編譯系統忽略多餘的檔案;具體配置語法為新增 extend-diff-ignore=…”一行內容。
如需排除 config.sub、config.guess 和 Makefile 檔案:
# Don't store changes on autogenerated files extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"
![]() |
Note |
---|---|
即使您無法刪除檔案,這種做法總可以正常工作。您無需在每次構建之前手動刪除檔案並手動進行恢復。 |
![]() |
Tip |
---|---|
如果您轉而使用 debian/source/local-options 檔案,您可以在生成的原始碼套件中隱藏該項設定。這種做法在本地非標準版本控制系統和您的打包工作有衝突時可能有用。 |
這個方法只適用於原生套件。
您可以使用這種做法在生成的原始碼套件中排除某些檔案;只需在 debian/source/options 檔案或者 debian/source/local-options 檔案中新增含有萬用字元的 “tar-ignore=…”一行內容即可。
![]() |
Note |
---|---|
例如,如果您的原生套件的原始碼套件使用了一些具有 .o 副檔名的檔案作為測試資料的話,Section 3.5, “devscripts” 的預設設定就過於激進了,這些檔案會被當作多餘的檔案預設自動排除。如需解決這個問題,您可以在 Section 3.5, “devscripts” 中的 DEBUILD_DPKG_BUILDPACKAGE_OPTS 引數中移除 -I 選項,同時在每個套件的 debian/source/local-options 檔案中新增 “tar-ignore=…”的配置行。 |
上游的構建系統設計為經過數個步驟以從原始碼發行檔案得到並在系統中安裝所生成的二進位制檔案。
Three typical build systems are described here. The situation of other
build systems are very similar to these since
debhelper
(7) the does most of the work and helps you
build a Debian package.
![]() |
Tip |
---|---|
在嘗試製作 Debian 套件之前,您應當熟悉瞭解上游原始碼所使用的構建系統並嘗試構建軟體。 |
使用 Autotools(autoconf + automake)包括四個步驟。
第一步通常由上游維護者完成並使用“make dist”命令生成上游原始碼壓縮包(tarball)。(所生成的原始碼壓縮包不僅含有原始的版本控制系統中的檔案,也含有其它生成的檔案。)
套件維護者至少要處理第二步到第四步的工作。可以在 debian/rules 檔案中使用“dh $@ --with autotools-dev”的命令以自動處理這些步驟。
套件維護者也可以想要處理第一步到第四步所有的工作。這時,可以在 debian/rules 檔案中使用“dh $@ --with autoreconf”命令。這樣會將所有自動生成的檔案更新到最新的版本,通常可以提供對新架構的更好支援。
對於使用 compat level(相容等級)10 或更高等級的原始碼套件,使用最簡單的“dh $@”而不帶“--with autoreconf”選項已可自動處理上述第一步到第四步全部內容。
如果您想進一步學習 Autotools,請參考:
使用 CMake 通常也包含四個步驟。
上游原始碼套件(tarball)不包含自動生成的檔案,通常是在第一步之後直接由 tar 命令打包生成。
套件維護者需要處理第二步到第四步的工作。
如果您想進一步學習 CMake,請參考:
Meson has 4 steps.
上游原始碼套件(tarball)不包含自動生成的檔案,通常是在第一步之後直接由 tar 命令打包生成。
套件維護者需要處理第二步到第四步的工作。
If you wish to learn more on the Meson, please see:
使用 Python distutils 通常包含三個步驟。
The upstream maintainer usually performs step 1 and builds the upstream tarball for distribution using the “python3 setup.py sdist” command.
The package maintainer needs to take care of step 2. This is realized simply by the “dh $@” command used in the debian/rules file.
These days, most upstream maintainers of Python packages use setuptools with
wheel. Since setuptools is an extension of distutils, this step 2 works as
expected even if setup.py
doesn’t explicitly uses
distutils.
If you wish to learn more on Python3, distutils, and setuptools, please see:
The Debian package is built with the debugging information but packaged into the binary package after stripping the debugging information as required by Chapter 10 - Files of the “Debian Policy Manual”.
參見
除錯資訊由 dh_strip 命令的預設行為自動打包並進行移除。所分離得到的除錯套件名具有 -dbgsym 的字尾。
在 Stretch 9.0 的釋出之後,如果在 debian/control 檔案中從未定義過任何 -dbg 軟體包,則不需任何特殊配置。
如果在 debian/control 檔案中曾經定義過 -dbg 套件,在 Stretch 9.0 釋出之後對舊套件更新需要進行額外的處理。
打包軟體程式庫需要您投入更多的工作。下面有一些打包軟體程式庫的提醒和建議:
在打包共享程式庫軟體之前,請查閱:
如需研究其歷史背景,請參見:
Debian lenny(5.0,2009年5月)中引入的 dpkg 符號支援可以幫助我們管理同一共享鏈接程式庫套件的向後 ABI 相容性(backward ABI compatibility)。二進位制套件中的 DEBIAN/symbols 檔案提供了每個符號及其對應的最小版本號。
一個極其簡化的軟體程式庫打包流程大概如下所示。
從前一個二進位制套件中使用“dpkg-deb -e”命令解壓縮得到舊有的 DEBIAN/symbols 檔案。
將其複製為 debian/binarypackage.symbols 檔案。
構建二進位制套件。
如果 dpkg-gensymbols 命令警告添加了新的符號的話:
如果 dpkg-gensymbols 命令不報和新連結符號有關的警告:
如需瞭解詳細資訊,您應當閱讀下列第一手參考資料。
您也應當檢視:
![]() |
Tip |
---|---|
For C++ libraries and other cases where the tracking of symbols is problematic, follow 8.6.4 The shlibs system of the “Debian Policy Manual”, instead. Please make sure to erase the empty debian/binarypackage.symbols file generated by the debmake command. For this case, the DEBIAN/shlibs file is used. |
當您打包新版本的程式庫套件而且此次更新影響到其它的套件時,您必須對 release.debian.org 偽套件提交一個變遷 bug 報告並附帶一個ben 檔案;您可以使用 reportbug 工具進行提交。提交後,請等待發行團隊的稽核批准方可進行下一步。
發行團隊提供了變遷追蹤系統。參見 變遷(Transition)。
![]() |
Caution |
---|---|
請確保您按照 Section 5.7.1.3, “程式庫套件名稱” 的描述正確地對二進位制套件進行了重命名。 |
debconf 套件可以幫助我們在下列兩種情況下配置套件:
使用選單介面進行互動式配置(對話方塊(dialog)、gnome、kde 等等)
套件安裝時的所有使用者互動都必須由這裡的 debconf 系統進行處理,下列配置檔案對這個過程進行控制。
debian/binarypackage.config
debian/binarypackage.template
套件配置指令碼
See dh_installdebconf(1), debconf(7), debconf-devel(7) and 3.9.1 Prompting in maintainer scripts in the “Debian Policy Manual”.
Debian wheezy(7.0,2013年5月)在 dpkg 和 apt 中引入了對跨架構二進位制套件安裝的多架構支援(特別是 i386 架構和 amd64 架構,但也支援其它的組合),這部分內容值得我們額外關注。
您應當詳細閱讀下列參考內容。
Ubuntu 維基(上游)
Debian 維基(Debian 的現狀)
多架構支援使用三元組(<triplet>)的值,例如 i386-linux-gnu 和 x86_64-linux-gnu;它們出現在共享連結程式庫的安裝路徑中,例如 /usr/lib/<triplet>/,等等。
不過,在 debian/rules 檔案中用於 override_dh_* 目標的三元組 <triplet> 值需要由維護者手動進行顯性設定。三元組 <triplet> 的值可由 $(DEB_HOST_MULTIARCH) 變數在 debian/rules 檔案中取得到,具體方法如下:
DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) ... override_dh_install: mkdir -p package1/lib/$(DEB_HOST_MULTIARCH) cp -dR tmp/lib/. package1/lib/$(DEB_HOST_MULTIARCH)
參見:
Debian 政策要求遵守檔案系統層級標準。其中 /usr/lib:程式和套件的程式庫 宣告“/usr/lib 包含目標檔案、程式庫和其它不應由使用者或 shell 指令碼直接呼叫的內部二進位制檔案。”
Debian 在檔案系統層級標準的基礎上新增一項例外,即使用 /usr/lib/<triplet>/ 而非 /usr/lib<qual>/(例如,/lib32/ 和 /lib64/)以對多架構程式庫提供支持。
Table 5.1. 多架構程式庫路徑選項
經典路徑 | i386 多體系架構路徑 | amd64 多體系架構路徑 |
---|---|---|
/lib/ |
/lib/i386-linux-gnu/ |
/lib/x86_64-linux-gnu/ |
/usr/lib/ |
/usr/lib/i386-linux-gnu/ |
/usr/lib/x86_64-linux-gnu/ |
對基於 Autotools 且由 debhelper (compat>=9)管理的套件來說,這些路徑設定已由 dh_auto_configure 命令自動處理。
對於其它使用不支援的構建系統的套件,您需要按照下面的方式手動調整安裝路徑。
所有啟用多架構的套件安裝至相同路徑的檔案必須內容完全相同。您必須小心處理,避免資料位元組序或者壓縮演算法等等問題帶來的檔案內容差異。
![]() |
Note |
---|---|
./configure 的 --libexecdir選項指定了由程式而非使用者所使用的可執行檔案的預設安裝路徑。其 Autotools 的預設值為 /usr/libexec/ 但在未啟用多架構特性的 Debian 系統上其預設值是 /usr/lib/。如果這些可執行程式屬於被標記為“Multi-arch: foreign”的套件,最好還是使用例如 /usr/lib/ 或者 /usr/lib/套件名 這樣的路徑而非使用 dh_auto_configure 設定的 /usr/lib/<triplet>/ 路徑。GNU 程式設計規範:7.2.5 用於安裝目錄的變數 對 libexecdir 的描述是“libexecdir 的定義對所有套件相同,所以您應當將您的資料安裝在其下的一個子目錄中。大多數套件將資料安裝至 $(libexecdir)/package-name/ 之中……”(在與 Debian 政策不衝突的前提下,遵守 GNU 的標準總是更好的。) |
位於預設路徑 /usr/lib/ 和 /usr/lib/<triplet>/ 的共享程式庫可被自動載入。
對位於其它路徑的共享程式庫,必須使用 pkg-config 命令設定 GCC 選項 -l 以正確進行載入。
在支援多架構的 Debian 系統上,GCC 預設會同時包含、使用 /usr/include/ 和 /usr/include/<triplet>/ 下的標頭檔案。
如果標頭檔案不在這些路徑中,必須使用 pkg-config 命令設定 GCC 的 -I 引數以使得“#include <foo.h>”正常工作。
Table 5.2. 多架構標頭檔案路徑選項
經典路徑 | i386 多體系架構路徑 | amd64 多體系架構路徑 |
---|---|---|
/usr/include/ |
/usr/include/i386-linux-gnu/ |
/usr/include/x86_64-linux-gnu/ |
/usr/include/ 套件名 / |
/usr/include/i386-linux-gnu/ 套件名 / |
/usr/include/x86_64-linux-gnu/ 套件名 / |
/usr/lib/i386-linux-gnu/ 套件名 / |
/usr/lib/x86_64-linux-gnu/ 軟體包名 / |
為程式庫檔案使用 /usr/lib/<triplet>/套件名/ 路徑可幫助上游維護者對使用 /usr/lib/<triplet> 的多架構系統和使用 /usr/lib<qual>/ 的雙架構系統使用相同的安裝指令碼。[18]
使用包含 packagename 的檔案路徑也使得在同一系統上同時安裝多個架構的開發程式庫成為可能。
自 Debian jessie(8.0 開始)的編譯器強化支援要求我們在打包時加以注意。
您應當詳細閱讀下列參考內容。
debmake 命令會對 debian/rules 檔案中按需新增 DEB_BUILD_MAINT_OPTIONS、DEB_CFLAGS_MAINT_APPEND 和 DEB_LDFLAGS_MAINT_APPEND 的專案(參見 Chapter 4, 簡單例子 和 dpkg-buildflags(1))。
DEP-8 定義了 debian/tests/control 檔案的格式,它是 RFC822 風格的測試元資料檔案,用於 Debian 套件的持續整合(CI)。
它在完成構建包含 debian/tests/control 文件的原始碼套件、得到二進位制包之後發揮作用。在執行 autopkgtest 命令時,所生成的二進位制套件會根據這個檔案在虛擬環境中自動進行安裝和測試。
See documents in the /usr/share/doc/autopkgtest/ directory and 4. autopkgtest: Automatic testing for packages of the “Ubuntu Packaging Guide”.
![]() |
Note |
---|---|
Testing of the binary packages during their building time can be accomodated
by |
您可以在 Debian 系統上探索使用不同的持續整合系統。
Debian packaging practices are moving target. Please keep your eyes on DEP - Debian Enhancement Proposals.
Debian 關心對新硬體架構的移植工作。新架構的移植工作對自主生成(bootstrapping)操作有所要求,以完成對初始最小本地構建系統的交叉編譯。為了在自主生成時避免構建依賴成環的問題,需要使用 配置型別(profile) 的構建功能特性來縮減所需構建依賴。
![]() |
Tip |
---|---|
如果一個核心套件 |
reportbug 命令用於提交 binarypackage 套件的錯誤報告;usr/share/bug/binarypackage/ 可以對針對該軟體所提交報告的內容進行設定。
dh_bugfiles 命令將安裝以下位於 debian/ 目錄中的的模板檔案。
debian/binarypackage.bug-control → usr/share/bug/binarypackage/control
debian/binarypackage.bug-presubj → usr/share/bug/binarypackage/presubj
debian/binarypackage.bug-script → usr/share/bug/binarypackage or usr/share/bug/binarypackage/script
參見 dh_bugfiles(1) 和 為開發者提供的 reportbug 功能特性
![]() |
Tip |
---|---|
如果您總是需要提醒提交報告的使用者某些注意事項或詢問他們某些問題,使用這些檔案可以將這個過程自動化。 |
[10] 對九成以上的套件來說,套件名稱都不會超過 24 個字元;上游版本號通常不超過 10 個字元,而 Debian 修訂版本號也通常不超過 3 個字元。
[11] Use of the “debmake -t …” command or “git deborig -f HEAD” can help this workflow. See Section 6.2, “Snapshot upstream tarball (-d, -t)” and dgit-maint-merge(7).
[12] This simplicity is available since version 7 of the debhelper package. This guide assumes the use of debhelper version 13 or newer.
[13] debmake 命令會產生稍微複雜一些的 debian/rules 檔案。雖然如此,其核心結構沒有什麼變化。
[14] 如果您在使用 vim 編輯器,請確保使用“:wq”命令對內容進行儲存。
[15] 程式以前會在內部呼叫來自 devscripts 軟體包的 licensecheck 命令來進行檢查。現在的 licensecheck 命令由獨立的 licensecheck 套件所提供,相較從前的實現也有了較大的改進。
[16] 該文件是在 symbols 檔案被引入之前寫成的。
[17] 在第六章 - 開發(-DEV)套件中,存在強烈的使用含有 SONAME 版本號的 -dev 套件名而非僅使用 -dev 作為名稱的偏好,但前 ftp-master 成員(Steve Langasek)對此有不同意見。請注意該文件在 multiarch 系統和 symbols 引入之前寫成,可能有一定程度的過時。
[18] 這個路徑和 FHS 相容。檔案系統層級標準:/usr/lib:程式和套件的程式庫 稱“應用程式可以使用 /usr/lib 下的一個子目錄。如果一個應用程式使用一個子目錄,所有由此程式所使用的架構相關資料均須放置於該子目錄下。”