釋出你的開源軟體到 Ubuntu PPA

hedzr發表於2021-12-21
Ubuntu
For an individual, here is a simple guide to show you howto publish and host your own deb to Ubuntu PPA.

Checklist

  1. An Ubuntu Machine

  2. SSH Keys Ready

    參考：[ssh-short-guide] （略）

  3. Preparing your GPG Keys

    參考：gpg-short-guide

  4. Setting up a Launchpad Account (aka: Ubuntu One Account)
  5. Creating your own PPA

  6. Publishing a first test package

    1. Backstaging Information

      參考：[creating deb from scratch]

      參考：[creating deb from source tree]

    2. Preparing the source code
    3. Preparing the Debian package control files
    4. Building the source package
    5. Uploading the package

  7. Using a PPA

    1. Installing the package
    2. Deleting a package

寫在前面

在 Linux 發行版中，包管理幾乎可以劃為兩大流派：rpm 和 deb。

pacman 與 archlinux 只是小眾就不提了。

zypper 只不過是 rpm 的上層，和 yum、dnf 並無本質的差別。

本文以及近來相似的文章都聚焦在 deb 發行方面。在 [從零開始製作 deb 包] 中我們已經介紹了 binary package 的構建，這樣構建的 deb 包能夠被使用者直接下載並通過命令 dpkg -i package.deb 的方式安裝，可以說是大大提高了使用者取用的方便性。但這種 deb 包不那麼容易被公開發行到包管理體系中——也不是絕對不行，但你需要為其準備太多的輔助檔案才可以。

而在本文中我們將會講述 source package 的入門。這種方式前提在於你是原始碼構建人員，對於原始碼的構建流程很熟悉，那麼通過 Debian 新維護者手冊 的指導你就能非常容易地構建出包管理系統滿意的發行包。此發行包（Bundle）中除了 deb 安裝包之外，通常還包括原始碼 tarball，以及具備版本跟蹤記錄的輔助檔案。使用 Debian 提供的工具 dput，你可以將該發行包（Bundle）推送到公共伺服器，使用者能夠使用 apt install package 的方式安裝它，這也是 Debian 系發行版的最佳發行方案。

發行包（Bundle）可以被髮布到 Debian/Unubtu 官方認證並維護的公共伺服器，但這需要若干前提，你需要提出申請並獲得維護團隊的許可。

如果你有心想要提供足夠正式而官方的 ppa 發行，使用 ppa 官網的註冊入口：

但是什麼代開發漂的還是別去搞汙染吧。

In PPA Way

對於獨立開發者來說，被核心源（main，restrited，universe）所接納，並不是一件容易的事。然而，開源的世界並不會關門，所以 ppa 可能是獨立開發者的最佳選擇。

PPA 是 Personal Package Archive 的縮寫，顧名思義，ppa 代表著一個供個人開發者釋出軟體包的環境、平臺，或者說基礎架構。

PPA 是由 launchpad.net 承載的。而 launchpad.net 是 Canonical 公司維護的網站，他允許軟體開發者在這裡自由地發行軟體，通過 launchpad 發行的軟體包，在 Ubuntu apt 體系中通過 ppa 的方式能夠享有核心軟體包的幾乎同等的待遇。你可以這樣安裝來自於某個 ppa 所提供的軟體包：

$ sudo add-apt-repository ppa:hedzr/test-ppa
$ sudo apt update
$ sudo apt install testpackage

Canonical 是 Ubuntu.com 的擁有者和運營者。

值得一提的是，ppa 是反哺的一個好的例證，現在（至少從 Debian 7 起）我們也可以在 Debian 原生作業系統中直接使用 ppa 安裝軟體，不再是 Ubuntu 系獨有。

使用 ppa 做軟體包分發的比較典型的例子是關於 Oracle Java SDK 的安裝，有好事者為其建立了 ppa 分發點，避免了去 Oracle 官網註冊帳號，手動確認 license，手動下載，手動執行安裝包完成 Java SDK 包的不文明方式。不過嚴格地說，這樣做有侵權的嫌疑，所以我早就不採用 Java 開發轉而搞 Golang 開發了，實在不行了我就去 C++，犯得著弄 Java 這種蠢笨的東西嗎。

釋出前準備

前提

為了釋出到 PPA，你需要一臺 Ubuntu 系統。幸運的是，在 Windows 中，你可以使用 WSL 環境，它就是 Ubuntu 的。而在 macOS 中，利用 VirtualBox，可選地使用 vagrant，你可以輕易地得到 Ubuntu Server 環境，非常輕量，基本上沒有什麼額外的負擔。

具體如何準備你的 Ubuntu 環境，如何與其連線，如同傳輸程式碼到該環境（rsync YYDS），本文就不予描述了，這算是基礎知識吧，你都在打算向 Ubuntu 社群貢獻個人的力量了，搞不懂我說的這些東西，未免很是說不過去。

一個輔助的參考在 Ubuntu Server 安裝提要 ，在這裡我介紹了一些讓你的 VM 更好用的 tips。

在這臺 Ubuntu 系統中，安裝必須的軟體包：

sudo apt install gnupg dput dh-make devscripts lintian gpg fakeroot
sudo apt install git make build-essentials

由於我們的案例是以 C++ 程式碼為例，所以也安裝 build-essential。

SSH Key Ready

在 Ubuntu 中，你已經有 SSH 環境，你已經有一個 SSH Key。

你可能也已經準備好了免密碼 sudo，這不是必須的，但可能是最好做到的，否則輸入密碼有可能很是煩惱。

GPG Key Ready

為了釋出到 PPA，你需要有 GPG Key，而且你要將其釋出到 keyserver.ubuntu.com 上去。

和 GPG 相關的一個速查表可以查閱 GPG Short Guide 。如果感覺需要更系統地瞭解 GPG 有關知識，你需要去搜尋一下了，這不是什麼高難問題——它的門檻在於：GPG 是一個和加密體系密切相關的概念，所以你需要大量的背景知識才能深入理解和用好它——但這並不妨礙普通人也能很容易地使用 GPG 做日常的簽名、簽署、加解密文件或郵件等工作。

GPG 標定一個身份，此身份與一個（或者多個）Email 郵箱地址相關聯以證實該身份。你需要使用一個穩定的郵箱來建立一個 GPG Key（包含公鑰和私鑰）。我們建議你建立一個 4096 bits 的金鑰。

一個重要的細節是，ppa 只能使用你的主金鑰來完成發包，或者精確地說，你只有用主金鑰來簽署要分發的軟體包，上傳之後 ppa 才能正確鑑定該包的有效性。因為 ppa 在登記你的 GPG 公鑰時，不接受 subkey。

或許，這並不是真的，也許只是因為網路環境的原因，因為由於眾所周知的原因，在 launchpad 上各個頁面之間的行走有很多問題，我不確定網路丟包、阻塞等會不會對登記 GPG Key 造成了影響。

但我也不想為此消耗更多精力了。

作為一個 Workaround，你在自己的宿主機上建立了 GPG 金鑰，你可以繼續建立子金鑰。然後你會匯出自己的主金鑰（私鑰+公鑰），注意此時不要匯出子金鑰，然後將匯出的金鑰匯入到 Ubuntu 系統上就可以很好地完成簽名了。

環境變數

對於 deb 構建來說，我們在 .bashrc 中新增環境變數：

DEBEMAIL="your-email@gmail.com"
DEBFULLNAME="your fullname"
export DEBEMAIL DEBFULLNAME
#DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc"
#DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID="Your_GPG_keyID"
export DEBSIGN_KEYID

請自行修正變數值。

Launchpad 賬戶

PPA 是由 launchpad.net 提供的一種軟體包發行途徑。所以你必須首先訪問 launchpad.net/+login 申請一個 launchpad 賬戶。

你需要知道的是 launchpad.net 是由 Canonical 公司運營的，而且 Ubuntu.com 也是他們家運營的，所以 launchpad 賬戶實際上也就是 Ubuntu One 賬戶，這一組站點是一家人。

因而申請連結將會跳轉到 Ubuntu One 註冊頁面。

在這裡需要注意的是，申請賬戶使用的 email 地址必須和 GPG Key 使用同樣的地址。

話不多說，申請了賬戶之後，首先確認 email 地址有效，然後新增你的 SSH，GPG Key 到你的使用者中心頁面裡。假設你使用使用者名稱 hedzr 註冊了賬戶，那麼你的頁面就在 https://launchpad.net/~hedzr，在這個頁面裡，依次新增 SSH Key，GPG Key 到相應的條目中，然後你的頁面看起來和下圖比較像：

image-20211218095834885

其中，新增 OpenPGP keys 的連結為：https://launchpad.net/~hedzr/+editpgpkeys

新增 SSH keys 的連結為 https://launchpad.net/~hedzr/+editsshkeys

建立 PPA

現在可以使用連結 Create a new PPA 建立你的第一個 ppa 了。

這一步非常簡單，不會有國產特色，直接明瞭就能搞定。

你可以建立的 ppa 數量沒有明顯的限制，每個 ppa 通常有 2GB 的容量。所以我們要求你首先建立一個名為 test-ppa 的 PPA，來進行下面的工作。

建立好的 ppa 具有 ppa:<使用者名稱>/<ppa-name> 這樣的唯一標識，使用者將會使用這樣的語法來新增你的 ppa：

sudo apt-add-repository ppa:hedzr/test-ppa

請自行替換必要的欄位。

釋出你的第一個軟體包

我們已經知道 deb 的構建有兩種方式：

  1. 從 binary package 構建 deb：

  2. 從 source package 構建 deb：

    • 釋出到 ppa 要求你必須提交原始碼，並且你的原始碼一定是可以編譯的。這個話題延展開會很巨大。

本文以 C/C++ 原始碼為例對後者（Source Package 方式）進行講解。

準備原始碼

在 Ubuntu 裡，我們在 $HOME 開始釋出工作。

首先是建立工作目錄 testpackage 並新增原始碼包（source package）。所謂的 source package 一般來說包含了源程式程式碼和構建所需的指令碼，通常是 Makefile，或者 CMakeLists.txt 等等。

工作目錄

首先是建立工作目錄：

mkdir -pv ~/deb/testpackage.work/testpackage
cd ~/deb/testpackage.work/testpackage
  1. 我們會做多個工作，所以總的來說是 deb/；
  2. .deb 的構建都是輸出到 source package 的上一級目錄，所以我們使用 testpackage.work/testpackage 兩級目錄結構來放置原始碼檔案
  3. 將來 .deb 檔案就能輸出到 testpackage.work/ 之中。

C 原始碼 main.c

並且就地建立一個 main.c：

cat > main.c <<EOF
#include <stdio.h>

int main()
{
  printf("Hello world!\n");
}
EOF

C 專案構建 Makefile

然後是 Makefile，這個 Makefile 必須有 all 和 install 兩個 Targets。

實際上只有 install 是必須的，此外 make 的預設 target 必須能夠構建出相應的二進位制結果，並且能夠被 install 正確使用。

Makefile 的相關知識也很難簡明講解。所以你首先需要這樣一個 Makefile：

BINDIR := /usr/bin

all:
    gcc main.c -o my_hello_world

install:
    mkdir -p ${DESTDIR}${BINDIR}
    cp my_hello_world ${DESTDIR}${BINDIR}/

我們使用命令列直接建立它：

echo -e 'BINDIR := /usr/bin

all:
\tgcc main.c -o my_hello_world

install:
\tmkdir -p ${DESTDIR}${BINDIR}
\tcp my_hello_world ${DESTDIR}${BINDIR}/
' > Makefile

注意為了保證 Makefile 格式正確（每個 target 的命令序列必須用 TAB 製表符進行縮排），所以我們使用 echo -e 並明確地使用 \t 轉義字元來表達縮排。

你可以在工作目錄下嘗試構建：

make all

我們已經知道 ppa 伺服器會使用構建伺服器來構建我們上傳的 source package ，此時 ${DESTDIR} 會由構建伺服器設定一個本地值。但對我們本機構建或者使用者通過 apt install構建時，它通常沒有指定值。

${BINDIR} 則被預設為值 /usr/bin，這也是我們安裝軟體包可執行檔案的預設目的地。

基於原始碼包建立軟體包的源資訊和控制檔案

C 原始碼很簡單，現在我們要建立 debian 資料夾和一系列控制檔案了：

dh_make -p testpackage_0.0.0.1 --single --native --copyright apache --email $DEBEMAIL

你可以選擇其它版權協議，例如 mit 等等。

版本號：應該是 4 節，通常用到前三節，最後一節是釋出緊急補丁時才會用到，也參考 semver 以及 debian 新維護者手冊的說明。

對於 deb 的 source package 構建方式來說，它使用一個 debian 資料夾來放置 deb 打包所需的控制檔案。

這和 binary package 的 DEBIAN 資料夾是不同的。

dh_make 將會詢問你若干問題，回答完畢後 debian 資料夾中會有一系列的檔案。其中名為 *.ex 的檔案是可選的，例如 postinst.ex，如果你想要編寫 postinst 指令碼的話，可以將它重新命名為 postinst，這個檔案中已經帶有必須的骨架，你聚焦在你的邏輯上即可。但如果你不需要編寫 postinst 指令碼，那麼 postinst.ex 是可以安全地刪除掉的：

rm debian/*.{ex,EX}

在 dh_make 執行之後，所生成的檔案都在 debian/ 之中：

image-20211218104317092

複查控制檔案

debian/README*

這些檔案提供文件描述，你可以修改它們以表述你的軟體包的用途。

debian/changelog

最重要的一個檔案，每當升級時，你需要在其中新增新版本的描述資訊。沒有正確的新版本描述資訊的小節的話，上傳和釋出不能成功完成。

我們需要修訂一下該檔案：

perl -i -pe "s/unstable/$(lsb_release -cs)/" debian/changelog

因為我們需要的是一個針對具體 Ubuntu 版本（案例中為 20.04）的安裝包，暫時不會涉及到 multiarch 或者 any 模式。

現在它的內容像這樣，其中 unstable 已經被替換為 focal：

testpackage (0.0.0.1) focal; urgency=medium

  * Initial Release.

 -- hedzr <hedzrz@gmail.com>  Tue, 07 Dec 2021 09:36:35 +0000

後文有關升級部分的描述會進一步闡述此文件。

debian/control

同樣很重要的檔案，這個檔案會在 debuild 時分被重構為 DEBIAN/control。

control 包含了軟體包的描述資訊，它的關鍵資訊基本來自於dh_make 時你的回答。

對剛剛生成的 control 我們還需要一點點修訂，通常涉及到 Section，Homepage，Vcs-Browser，Vcs-git，Description 等欄位。你需要根據自己的具體情況來設定這些值。

修訂過的 control 長的這樣：

Source: testpackage
Section: utils
Priority: optional
Maintainer: hedzr (hz, hedzr) <hedzrz@gmail.com>
Build-Depends: debhelper-compat (= 12)
Standards-Version: 4.4.1
Homepage: https://testpackage.foobar.org
Vcs-Browser: https://github.com/foobar/testpackage
Vcs-Git: https://github.com/foobar/testpackage.git

Package: testpackage
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: A short description
  A long description,
  very long indeed!

其中 Description 欄位可以多行，必須是最後一個欄位，多行文字的行首需要至少一個空格的縮排。

debian/rules

在 source package 構建中，rules 可能是最重要的一個檔案，因為它為你提供了定製、修改標準編譯構建行為的機會。

在本文中不對 rules 進行詳細描述，因為這是一個挑戰個人能力的龐大的話題。我們使用預設生成的版本而不做任何改變：

#!/usr/bin/make -f
# See debhelper(7) (uncomment to enable)
# output every command that modifies files on the build system.
#export DH_VERBOSE = 1


# see FEATURE AREAS in dpkg-buildflags(1)
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all

# see ENVIRONMENT in dpkg-buildflags(1)
# package maintainers to append CFLAGS
#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
# package maintainers to append LDFLAGS
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed


%:
    dh $@


# dh_make generated override targets
# This is example for Cmake (See https://bugs.debian.org/641051 )
#override_dh_auto_configure:
#    dh_auto_configure -- #    -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)

在下一篇專題文章中，我們會對這個檔案有節制地進行調整，屆時將會介紹一部分相關情況。如果你對此有濃厚的興趣，那麼不必等待我們的入門級別的系列文章釋出，徑直可往 Debian 新維護者手冊 嘗試研究。

More...

其它檔案你可以依次瀏覽，根據需要進行修訂。但作為第一個試驗目的的軟體包，就這麼就可以了。

你可以新增 postinst, postrm 等等指令碼，這方面沒有什麼額外的不同，所以你可以參考 從零開始製作 deb 檔案 - Create .deb From Scratch，也可以查閱 MaintainerScripts。

注意 dh_make 已經替我們生成了這些檔案的完整模板，只是它們以 .ex 字尾名結尾，所以當你想要自己的版本時，簡單地重新命名這些 skeleton 檔案即可。

有時候你需要複查這些指令碼檔案的可執行許可權是否在場，確保它們至少是 0755。

讓我們推進到下一步吧。

構建可分發包

構建 deb，並用我們的專用 subkey 簽署它們。

debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1

-S 表示從原始碼編譯構建；

-us -uc 指定了簽署的選項；

結果是生成一組檔案 deb 包

testpackage_0.0.0.1.dsc
testpackage_0.0.0.1.tar.xz
testpackage_0.0.0.1_source.build
testpackage_0.0.0.1_source.buildinfo
testpackage_0.0.0.1_source.changes

上傳到我們的 ppa

testpackage_0.0.0.1_source.changes 是上傳所需要的資訊檔案，我們剛剛生成的 testpackage_0.0.0.1.* 現在可以被上傳到我們的 ppa 了：

Z="$(perl -ne 'print $1 if /dpkg-genchanges --build=source >(.*)/' /tmp/debuild.log)"
dput ppa:hedzr/testppa $Z

它等價於：

dput ppa:hedzr/testppa testpackage_0.0.0.1_source.changes

可能發生的問題

gpg.errors.BadSignatures

如果你的 GPG Key 有若干 subkey，此簽署將會不夠正確，dput 上傳前校驗 package 檔案會失敗。

$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Checking signature on .changes
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in <module>
    load_entry_point('dput===1.0.3ubuntu1', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1030, in main
    files_to_upload = verify_files(
  File "/usr/share/dput/dput/dput.py", line 374, in verify_files
    verify_signature(
  File "/usr/share/dput/dput/dput.py", line 274, in verify_signature
    assert_good_signature_or_exit(changes_file_path)
  File "/usr/share/dput/dput/dput.py", line 258, in assert_good_signature_or_exit
    crypto.check_file_signature(infile)
  File "/usr/share/dput/dput/crypto.py", line 93, in check_file_signature
    (_, verify_result) = context.verify(infile)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 541, in verify
    raise errors.BadSignatures(results[1], results=results)
gpg.errors.BadSignatures: DA3963683E1153984E7FBE218D9B6C4242615E10: General error

此時上傳沒有被完成。

忽略簽名看看更多

如果你想，可以加上 --unchecked 重試

dput --unchecked ppa:hedzr/testppa testpackage_0.0.0.1_source.changes
https://askubuntu.com/questio...

此時會顯示剩餘的上傳過程：

$ dput -f -u  ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.1.dsc: done.
  Uploading testpackage_0.0.0.1.tar.xz: done.
  Uploading testpackage_0.0.0.1_source.buildinfo: done.
  Uploading testpackage_0.0.0.1_source.changes: done.
Successfully uploaded packages.

不過，這並不是真的。因為此時 dput 工作在 dry-run 模式。

解決問題

解決的辦法是編輯你的 GPG Key，刪除所有 subkeys 僅保留主 key：

$ gpg --edit-key 17AFB9B1
key 2
delkey
key 1
delkey
save

假設你有兩個 subkeys，上面的命令序列依次定位每個 subkey，刪除之，最後存檔退出。

這是為了順應 launchpad 的限制，它們家只能登記你的主 key 只能以主 key 進行 verify。

現在刪除錯誤的包後重新打包：

$ rm ../testpackage_*
$ debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1
$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.1.dsc: done.
  Uploading testpackage_0.0.0.1.tar.xz: done.
  Uploading testpackage_0.0.0.1_source.buildinfo: done.
  Uploading testpackage_0.0.0.1_source.changes: done.
Successfully uploaded packages.

幾分鐘之後，你會收到 Launchpad 的通知郵件，表明它們已經接受了我們剛剛上傳的軟體包，

現在可以從你的私人 ppa 安裝它了：

sudo add-apt-repository ppa:hedzr/test-ppa
sudo apt update
sudo apt install testpackage

可以注意到我們構建的是一個 xz 格式的 tarball，並非 deb 檔案。不過這點區別並不很重要，因為性質是一樣的。此外，還記得我們前文介紹過的 deb 的格式嗎，它只不過是控制檔案 xz 包和內容檔案 xz 包的捆綁組合（用 ar 格式），所以實際上並無分別。

從源頭解決問題

打包所使用的伺服器往往並非你的主力工作機，所以這臺伺服器上的 gpg keyrings 實際上也是通過匯入你的 gpg 私鑰檔案的方式構建起來的。

當你在主力工作機上匯出私鑰時，可以使用 ! 字尾來要求僅匯出指定金鑰，不對 subkeys 進行匯出：

gpg --armor --output user.gpg.private.key.asc --export-secret-keys MASTER-KEYID!

這樣做，在伺服器匯入之後就只有主金鑰了。

類似地在其它一些場所也有同樣的需要精確指定而不是最佳匹配的情況，均可使用 ! 字尾大法。

Error: signing key fingerprint does not exist

當首次試驗 testpackage 時，我可以理解你的急迫心情，因為當初我也是那樣的。但事實是，你要有耐心，從本地成功上傳之後，你不會立即看到 launchpad ppa 的狀態更新，你不會立即收到郵件，如果你的軟體包龐大且構建耗時，那麼這個情況會更嚴重。放心，會的。

此外，如果你收到郵件，很快就想嘗試安裝測試，那麼你可能收到 key 不存在的錯誤：

$ sudo add-apt-repository ppa:hedzr/test-ppa
 for testing
 More info: https://launchpad.net/~hedzr/+archive/ubuntu/test-ppa
Press [ENTER] to continue or Ctrl-c to cancel adding it.

Error: signing key fingerprint does not exist
Failed to add key.

BE PATIENT。launchpad 實際上需要為你的 ppa 建立一個新的 GPG Key，這個 GPG Key 需要一點點時間才能上傳到 keyserver.ubuntu.com 並需要一點點時間才能在 pool 中完成同步和分發，所以，等一等，retry，你不會在這裡困擾太久的。

其它資訊

Launchpad PPA for You

如果你對這個新 key 有一點點好奇的話，可以看看它：

$ apt-key list <Your_launchpad_username>

例如：

$ apt-key list hedzr
pub   rsa4096 2021-12-07 [SC]
      4AE7 90DF 4985 3D9E 55DE  41F9 A6E8 3CC2 BF06 44DD
uid           [ unknown] Launchpad PPA for Hedzr Yeh

確認 testpackage 資訊

# 檢視 包資訊 
apt info testpackage

# 顯示包中檔案
dpkg -L testpackage

作為使用者安裝 testpackage

在使用者的操作介面，他需要做這些事來安裝你的 testpackage：

$ sudo add-apt-repository ppa:hedzr/test-ppa
$ sudo apt update    # optional
$ sudo apt install testpackage

升級到新版本

當你準備好釋出下一個版本時，對於 debian 控制檔案來說，僅僅只需要修訂 debian/changelog 即可。一個樣本看起來就像這樣：

testpackage (0.0.0.2) focal; urgency=medium

  * Updated: fixed build error in source codes

 -- hedzr <hedzrz@gmail.com>  Tue, 08 Dec 2021 09:28:35 +0000

testpackage (0.0.0.1) focal; urgency=medium

  * Initial Release.

 -- hedzr <hedzrz@gmail.com>  Tue, 07 Dec 2021 09:36:35 +0000

你可以用 dch -i 或者 dch -v version-revision 來修改 changelog 檔案。

接下來是重新構建：

debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1

現在就會是有新版本生成：

-rw-r--r-- 1 hz hz 1569 Dec  8 01:29 ../testpackage_0.0.0.2.dsc
-rw-r--r-- 1 hz hz 7472 Dec  8 01:29 ../testpackage_0.0.0.2.tar.xz
-rw-r--r-- 1 hz hz 2354 Dec  8 01:29 ../testpackage_0.0.0.2_source.build
-rw-r--r-- 1 hz hz 6199 Dec  8 01:29 ../testpackage_0.0.0.2_source.buildinfo
-rw-r--r-- 1 hz hz 2033 Dec  8 01:29 ../testpackage_0.0.0.2_source.changes

於是你將上傳它到 ppa：

$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.2_source.changes
Checking signature on .changes
gpg: ../testpackage_0.0.0.2_source.changes: Valid signature from 2E6F77F217AFB9B1
Checking signature on .dsc
gpg: ../testpackage_0.0.0.2.dsc: Valid signature from 2E6F77F217AFB9B1
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.2.dsc: done.
  Uploading testpackage_0.0.0.2.tar.xz: done.
  Uploading testpackage_0.0.0.2_source.buildinfo: done.
  Uploading testpackage_0.0.0.2_source.changes: done.
Successfully uploaded packages.

耐心等待，新版本將會發布。

檢視 PPA 上的釋出狀態

對於 hedzr/test-ppa 來說，看這裡：https://launchpad.net/~hedzr/+archive/ubuntu/test-ppa/+packages

每個包名字可以展開，釋出不成功的包的 Builds 有失敗的 buildlog 連結，進去可以檢視到為何失敗。

一個 ppa 只有 2GB 大小，所以友善地利用公共開源空間可能不僅僅只是一個禮貌問題。

Bonus

當你的軟體包足夠穩定，足夠有用並進入了官方 ppa 時，甚至於進入了官方源時，在個人的 ppa 中所安裝的同名軟體包就有點不合時宜了。

ppa-purge 則可以讓使用者很簡單地清理從你的個人 ppa 中安裝的軟體包，並且以官方源或官方 ppa 源的同名軟體包來安裝和代替之。當然，如果尚未有同名正式版本在官方源中的話，這個軟體包將保持不變。

sudo ppa-purge ppa:<lp-name>/<ppa-name>

結束

這篇文章從下文中抽取了用例：

事實上，本文早期的學習來源之一在很大程度上就是這篇文章。

當然我的更大的老師是 Debian 新維護者手冊，你應該首先耐心將其通讀一遍，因為這個手冊裡講述了所有的關鍵概念，你必須至少有個印象才能理解 source package 構建中的各類細節，諸如 Depends 應該如何設定等等。

然而，通讀它，不必急著精讀它，而是藉助本文直接上手跑一遍，自己跑一個例項出來，再回頭去精讀比較適當。

然後 Debian Policy Manual 是非常重要的參考手冊，對於國人來說你需要面對沒有中文翻譯版本的它，但其語法是很簡單的，閱讀起來估計是5、6歲小孩的難度，你只需要有一定的計算機方向詞彙量就行。我們提到的，包括新維護者說冊提到的所有 debian/* 檔案在 Policy 手冊中有精細的描述，你想要編寫自己的進一步的控制檔案將必須參考該手冊。

我發覺下定決心要做一件事，那就當然做得到。一直以來我都避免做 Packaging 方面進一步的研究或者說學習，而是藉助於更簡便的途徑來做分發（比如放在 GitHub Releases 你下載就好了），但簡便或許就意味著使用者的不簡便，這就是最終我必須面對專業 Packaging 途徑的原因。但既然做了一些研究，那很容易就能發現一些資源就在那裡，但沒有人會刻意提示你某些東西在哪裡。怎麼辦呢？一般來說找到 usnet 這樣的專業的新聞組，提出問題時得到有用指示的概率比較大。但面向消費者的例如 quora 不見得是好選擇。我必須提示的是，Discord 或者 dev.to 在面對我所介紹的這些有關 Packaging 的細碎問題也沒有太多幫助。當然，終究你得藉助於 Google 才能找到我所說的那些渠道，也包括那些有用的博文。同樣地，我的，我想，對於有的人來說，這樣的真正介紹到要點的文章也理應是會很有用的。

參考

相關文章