Table of Contents
這裡有一些關於 Debian 打包的值得注意的小技巧。
Debian now enforces the source-only upload when developing packages. So
there may be 2 different *
.changes files:
您可以使用 debdiff 命令來對比兩個 Debian 套件組成的差別。
$ debdiff old-package.dsc new-package.dsc
您也可以使用 debdiff 命令來對比兩組二進制 Debian 套件中的檔案列表。
$ debdiff old-package.changes new-package.changes
當檢查原始碼套件中哪些檔案被修改時,這個命令非常有用。它還可以用來檢測二進位制包中是否有檔案在更新過程中發生變動,比如被意外替換或刪除。
您可以使用 dget 命令來下載 Debian 套件原始碼的檔案集。
$ dget https://www.example.org/path/to/package_version-rev.dsc
您應該使用 piuparts 命令安裝生成的套件以自動進行測試。
$ sudo piuparts package_version-rev_arch.changes
![]() |
Note |
---|---|
這是一個非常慢的過程,因為它需要查詢遠端 APT 套件倉庫。 |
完成套件的測試後,您可以使用 debsign 命令對其進行簽名。
For uploading source-only package (normal):
$ debsign package_version-rev_source.changes
For uploading binary package:
$ debsign package_version-rev_arch.changes
使用 debsign 命令對包進行簽名後,您可以使用 dput 命令上傳 Debian 源和二進位制包的檔案集。
For uploading source-only package (normal):
$ dput package_version-rev_source.changes
For uploading binary package:
$ dput package_version-rev_arch.changes
上傳套件後,您將收到錯誤報告。 如《Debian 開發者參考》5.8. 處理缺陷 中所述,正確地管理這些錯誤是套件維護者的一項重要職責。
bts 命令是一個用以處理 Debian 缺陷追蹤系統 上的錯誤的便捷工具。
$ bts severity 123123 wishlist , tags -1 pending
git-buildpackage 套件提供了許多命令來使用 git 倉庫自動打包。
gbp import-orig:在 git 倉庫中匯入新的上遊原始碼。
gbp buildpackage:從 git 倉庫中構建 Debian 二進位制包。
--git-builder='sbuild -A -s --source-only-changes -v -d
unstable'
gbp pq、git-dpm 或 quilt(或者其別名 dquilt)命令用於管理相容 quilt 的補丁。
使用git-buildpackage套件來管理套件歷史,正成為絕大多數 Debian 維護者的實踐標準。
參見:
![]() |
Tip |
---|---|
放鬆。您並不需要使用全部的打包工具,您只需要使用您所需要的那個就行。 |
對於記錄在 snapshot.debian.org 歸檔中的名為 <source-package> 的 Debian 原始碼套件,可以生成包含所有 Debian 版本歷史的初始 git 儲存庫,如下所示。
$ gbp import-dscs --debsnap --pristine-tar '<source-package>'
對於使用 git-buildpackage 打包的 Debian 套件,遠端儲存庫 origin 上的 upstream 分支通常用於追蹤已釋出的上游原始碼的內容。
也可以通過將其遠端儲存庫命名為 upstream 而不是預設的 origin 來追蹤上游 git 倉庫。 然後,您可以通過使用 gitk 命令和 gbp-pq 命令進行挑選,輕鬆地將最近的上游更改新增到 Debian 修訂版中。
![]() |
Tip |
---|---|
“gbp import-orig --upstream-vcs-tag” 命令可以通過使用上游 git 倉庫中的指定標籤在 upstream 分支上建立一個合併提交的方式來生成乾淨的打包歷史資訊。 |
![]() |
Caution |
---|---|
已釋出的上游原始碼的內容可能與上游 git 儲存庫的相應內容並不完全匹配。 它可能包含一些自動生成的檔案或遺漏一些檔案。(Autotools、distutils......) |
The new dgit package offers commands to automate packaging activities using the git repository as an alternative to still popular gbp-buildpackage. Please read their guide:
Format: 3.0 (quilt)
" package with its changes flowing
both ways between the upstream Git repository and the Debian Git repository
which are tightly coupled.
Format: 3.0 (quilt)
" package with its changes flowing
mostly one way from the upstream Git repository to the Debian Git
repository.
Format: 3.0 (quilt)
" package with its Debian Git
repository which is kept usable also for people using gbp-buildpackage(1).
Format: 3.0 (native)
" package in the Debian Git
repository.
The dgit(1) command can push the easy-to-trace change history to the https://browse.dgit.debian.org/ site and can upload Debian package to the Debian repository properly without using dput(1).
For quasi-native Debian binary package
scheme situation described in Section 6.2, “Snapshot upstream tarball (-d, -t)” can be addressed
using alternative git deborig
approach adopting the
dgit-maint-merge(7) scheme when
debian/changelog
contains the non-native version number
with revision like 0.16-1
.
$ cd /path/to/upstream-git $ git rm -rf debian $ git tag -s upstream/0.16 $ git reset --hard HEAD^ $ git deborig $ sbuild
Here, for source format 3.0 (quilt)
, removal of files
under debian/
directory in the upstream tarball is
non-essential operation to quiet false positive warning from lintian.
For -1
revision, this use of
git-deborig
(1) as above is how this
debmake-doc
package generates the upstream tarball.
For -2
, -3
, … revisions, you need to
fetch and use the uploaded upstream tarball instead. For this,
origtargz
(1) may be handy.
The chroot for a clean package build environment can be created and managed using the tools described in Chapter 3, 工具的配置. [19]
以下是可用的套件構建命令的快速總結。 有很多方法可以做同樣的事情。
A clean unstable distribution chroot environment can be used as follows.
The chroot filesystem creation command for the unstable distribution
The master chroot filesystem path for the unstable distribution chroot filesystem
The package build command for the unstable distribution chroot
The command to update the unstable chroot
The command to login to the unstable chroot filesystem to modify it
Here, single "u" is predefined short alias for "unstable".
可以根據如下方式使用任意的 dist 版本環境。
用於 dist 版本的 chroot 檔案系統建立命令
dist 版本的 chroot 檔案系統的檔案路徑
dist 版本 chroot 的套件構建命令
更新 dist chroot 的命令
The command to login to the master chroot (source:dist) of the dist distribution environment to modify it persistently
![]() |
Tip |
---|---|
For building new experimental packages or for debugging buggy packages without using slow network access, this “sudo sbuild-shell dist” command can be used to pre-loaded some packages. Make sure to retain the backup of the original minimal chroot since changes are persistent and interfere with the normal test package building with the minimal chroot. |
![]() |
Tip |
---|---|
If your old chroot filesystem is missing packages such as libeatmydata1, ccache, and lintian, you may want to install these with the “sudo sbuild-shell dist” command. |
![]() |
Tip |
---|---|
When the orig.tar.gz file needs to be uploaded for a Debian revision other than 0 or 1 (e.g., for a security upload), add the -sa option to the end of dpkg-buildpackage, debuild, and sbuild commands. For the “gbp buildpackage” command, temporarily modify the builder setting of ~/.gbp.conf. |
![]() |
Note |
---|---|
本節中的描述過於簡潔,對大多數潛在的維護者都沒用。 這是作者的有意為之。 我們強烈建議您搜尋並閱讀與所用命令相關的所有文件。 |
Let’s assume that a bug report #bug_number was filed against your package, and it describes a problem that you can solve by editing the buggy file in the upstream source. Here’s what you need to do to create a new Debian revision of the package with the bugname.patch file recording the fix.
使用 dquilt 命令準備新的 Debian 套件修訂版本.
$ dquilt push -a $ dquilt new bugname.patch $ dquilt add buggy $ vim buggy ... $ dquilt refresh $ dquilt header -e $ dquilt pop -a $ dch -i
此外,如果套件是用 git-buildpackage 命令以其預設配置管理的 git 倉庫:
使用 gbp-pq 命令進行新的 Debian 修訂.
$ git checkout master $ gbp pq import $ vim buggy $ git add buggy $ git commit $ git tag pq/<newrev> $ gbp pq export $ gbp pq drop $ git add debian/patches/* $ dch -i $ git commit -a -m "Closes: #<bug_number>"
請確保簡明扼要地描述修復報告錯誤的更改並通過在 debian/changelog 檔案中新增 “Closes: #<bug_number>” 來關閉這些錯誤。
![]() |
Tip |
---|---|
在實驗時使用帶有版本字串的 debian/changelog 條目,例如 1.0.1-1~rc1 。然後,將這些更改日誌條目整理到官方套件的條目中。 |
如果 foo 包是以現代“3.0 (native)”或“3.0 (quilt)”格式正確打包的,則打包新的上游版本時需要將舊的 debian/ 目錄移動到新的原始碼路徑中。 這可以通過在新提取的原始碼路徑中執行“tar -xvzf /path/to/foo_oldversion.debian.tar.gz”命令來完成。[20] 當然,你還需要做一些修改。
有很多的工具可以用以處理這些情況。在使用這些軟體來更新上游版本後,請在 debian/changelog 檔案中簡要描述修復錯誤的上游修改,並新增 “Closes: #bug_number” 來關閉錯誤。
您可以使用來自 uupdate 套件中的 uupdate 命令來自動更新到新的上游原始碼。該命令需要舊的 Debian 原始碼套件和新的上游原始碼套件。
$ wget https://example.org/foo/foo-newversion.tar.gz $ cd foo-oldversion $ uupdate -v newversion ../foo-newversion.tar.gz ... $ cd ../foo-newversion $ while dquilt push; do dquilt refresh; done $ dch
您可以使用來自 uupdate 套件中的 uscan 命令來自動更新到新的上游原始碼。該命令需要包含 debian/watch 檔案的舊的 Debian 原始碼套件。
$ cd foo-oldversion $ uscan ... $ while dquilt push; do dquilt refresh; done $ dch
您可以使用來自 git-buildpackage 套件中的 “gbp import-orig --pristine-tar” 命令來自動更新到新的上游原始碼。該命令需要在 git 倉庫中的 Debian 原始碼和新的上游原始碼包。
$ ln -sf foo-newversion.tar.gz foo_newversion.orig.tar.gz $ cd foo-vcs $ git checkout master $ gbp pq import $ git checkout master $ gbp import-orig --pristine-tar ../foo_newversion.orig.tar.gz ... $ gbp pq rebase $ git checkout master $ gbp pq export $ gbp pq drop $ git add debian/patches $ dch -v <newversion> $ git commit -a -m "Refresh patches"
![]() |
Tip |
---|---|
如果上游也使用 git 倉庫,請為 gbp import-orig 命令加上 --upstream-vcs-tag 選項。 |
您可以使用來自 git-buildpackage 套件中的“gbp import-orig --pristine-tar --uscan”命令來自動更新到新的上游原始碼。該命令需要在 git 倉庫中的包含 debian/watch 檔案的 Debian 原始碼。
$ cd foo-vcs $ git checkout master $ gbp pq import $ git checkout master $ gbp import-orig --pristine-tar --uscan ... $ gbp pq rebase $ git checkout master $ gbp pq export $ gbp pq drop $ git add debian/patches $ dch -v <newversion> $ git commit -a -m "Refresh patches"
![]() |
Tip |
---|---|
如果上游也使用 git 倉庫,請為 gbp import-orig 命令加上 --upstream-vcs-tag 選項。 |
更新套件的風格並不是更新套件所必須的步驟。但是,這麼做可以讓您充分利用現代 debhelper 和 3.0 原始碼格式的所有能力。
您應該核對一下 DEP——Debian 增強提議 並且採用已接受的提議。
參見 ProjectsDebSrc3.0 以核對 Debian 工具鏈對新 Debian 原始碼格式的支援情況。
Common Debian Build System (CDBS)是 debhelper 套件的包裝系統。CDBS 基於 Makefile 包含機制並且由 debian/rules 檔案中設定的 DEB_* 變數配置。
在將 dh 命令引入第七版的 debhelper 套件之前,CDBS 是建立簡單乾淨的 debian/rules 檔案的唯一方法。
對於很多簡單的套件,現在 dh 命令使 debian/rules 檔案很簡潔,建議保持構建系統簡潔,而非使用冗長的 CDBS。
![]() |
Note |
---|---|
“CDBS 神奇地讓我用更少的命令來完成工作”和“我不懂新的 dh 的語法”都不是您繼續使用舊的 CDBS 系統的藉口。 |
對於一些複雜的套件,比如與 GNOME 相關的,當前的維護者有理由利用 CDBS 自動化完成他們的統一包裝。如果是這種情況,請不要費心從 CDBS 轉換為 dh 語法。
![]() |
Note |
---|---|
如果您正在與維護 團隊 合作,請遵循團隊的既定慣例。 |
將套件從 CDBS 轉換為 dh 語法時,請使用以下內容作為參考:
構建環境的預設語言環境是 C。
某些程式(如 Python3 的 read 函式)會根據區域設定改變行為。
新增以下程式碼到 debian/rules 檔案可以確保程式使用 C.UTF-8 的區域語言設定(locale)進行構建。
LC_ALL := C.UTF-8 export LC_ALL
如果上游文件是用舊編碼方案編碼的,那麼將它們轉換為 UTF-8 是個好主意。
請使用 libc-bin 包中的 iconv 命令來轉換純文字檔案的編碼。
$ iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt
使用 w3m(1) 將 HTML 檔案轉換為 UTF-8 純文字檔案。 執行此操作時,請確保在 UTF-8 語言環境下執行它。
$ LC_ALL=C.UTF-8 w3m -o display_charset=UTF-8 \ -cols 70 -dump -no-graph -T text/html \ < foo_in.html > foo_out.txt
在 debian/rules 檔案的 override_dh_* 目標中執行這些指令碼。
當您第一次對歸檔上傳套件時,您還需要包含原始的 orig.tar.gz 原始碼。
如果 Debian 修訂碼是 1 或者 0,這都是預設的。否則,您必須使用帶有 -sa 選項的 dpkg-buildpackage 命令。
![]() |
Tip |
---|---|
另一方面,-sd 選項將會強制排除原始的 orig.tar.gz 原始碼。 |
![]() |
Tip |
---|---|
新增至 ~/.bashrc 檔案。 |
如果當跳過上傳時,你在 debian/changelog 中建立了多個條目,你必須建立一個包含自上次上傳以來所有變更的 debian/changelog 檔案。這可以通過指定 dpkg-buildpackage 選項 -v 以及上次上傳的版本號,比如 1.2 來完成。
關於以下內容的 可以在 debhelper(7) 手冊頁中找到:
在數種不同構建條件下構建多種二進位制包
從引導程序中排除某些包(參見 BuildProfileSpec)
關於以下內容的提示可以在 dpkg-source(1) 手冊頁中找到:
多個上游原始碼套件的命名約定
將 Debian 更改記錄到上游原始碼套件中
儘管上游的原始碼有著所有構建 Debian 套件所需的資訊,找出使用何種選項的組合仍然不是一件簡單的事。
此外,上游的包可能更專注於功能的增強,而並不那麼重視向後相容性等特性,這是 Debian 打包實踐中的一個重要方面。
利用其他發行版的資訊是解決上述問題的一種選擇。
如果其他發行版是由 Debian 派生的,重新使用它是沒有價值的。
如果其他發行版是基於 RPM 的發行版,請參見 Repackage src.rpm。
通過 rget 命令,可以下載並開啟 src.rpm檔案。(請將 rget 指令碼新增至 PATH 中)
rget 指令碼.
#!/bin/sh FCSRPM=$(basename $1) mkdir ${FCSRPM}; cd ${FCSRPM}/ wget $1 rpm2cpio ${FCSRPM} | cpio -dium
許多上游原始碼套件包含 RPM 系統使用的、以 packagename.spec 或者 packagename.spec.in 命名的SPEC 檔案。這可以被用做 Debian 套件的基點。
當您遇到構建問題或者生成的二進位制程式核心轉儲時,您需要自行解決他們。這就是除錯(debug)。
This is too deep a topic to describe here. So, let me just list few pointers and hints for some typical debug tools.
更新 “/etc/security/limits.conf” 檔案來包含以下程式碼:
* soft core unlimited
gdb - The GNU Debugger
strace - 追蹤系統呼叫和訊號
ltrace - 追蹤程式庫呼叫
“perl -d:Trace script.pl” - 追蹤 Perl 指令碼
lsof - 按程序列出開啟的檔案
![]() |
Tip |
---|---|
script 命令能幫助記錄控制檯輸出。 |
![]() |
Tip |
---|---|
在 ssh 命令中搭配使用 screen 和 tmux 命令,能夠提供安全並且強健的遠端連線終端。 |
![]() |
Tip |
---|---|
libreply-perl(新的)套件和來自 libdevel-repl-perl(舊的)套件的 re.pl 命令為 Perl 提供了一個類似 Python 和 Shell 的 REPL (=READ + EVAL + PRINT + LOOP) 環境。 |
![]() |
Tip |
---|---|
rlwrap 和 rlfe 命令為所有互動命令提供了輸入行編輯功能。例如 “rlwrap dash -i”。 |
[19] The sbuild style chroot organization is deployed here. See https://wiki.debian.org/sbuild . Be careful since many HOWTOs use different chroot setups.
[20] 如果 foo 包是以舊的 1.0 格式打包的,則相對的,只要在新的原始碼路徑中執行“zcat /path/to/foo_oldversion.diff.gz|patch -p1”命令。
[21] 您可以使用 splitdiff 命令來將 big.diff 檔案分割成多個小的增量更新補丁檔案。