关于ubuntu:发布你的开源软件到-Ubuntu-PPA

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 官网的注册入口：

• Register a project
• Register a team

然而什么代开发漂的还是别去搞净化吧。

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 到相应的条目中，而后你的页面看起来和下图比拟像：

其中，增加 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：

   • 参考：从零开始制作 deb 文件 – Create .deb From Scratch

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/ 之中：

复查管制文件

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>

完结

这篇文章从下文中抽取了用例：

• Building a Debian (.deb) source package, and publishing it on an Ubuntu PPA – Saverio Miroddi

事实上，本文晚期的学习起源之一在很大水平上就是这篇文章。

当然我的更大的老师是 Debian 新维护者手册，你应该首先急躁将其通读一遍，因为这个手册里讲述了所有的要害概念，你必须至多有个印象能力了解 source package 构建中的各类细节，诸如 Depends 应该如何设定等等。

然而，通读它，不用急着精读它，而是借助本文间接上手跑一遍，本人跑一个实例进去，再回头去精读比拟适当。

而后 Debian Policy Manual 是十分重要的参考手册，对于国人来说你须要面对没有中文翻译版本的它，但其语法是很简略的，浏览起来预计是 5、6 岁小孩的难度，你只须要有肯定的计算机方向词汇量就行。咱们提到的，包含新维护者说册提到的所有 debian/* 文件在 Policy 手册中有精密的形容，你想要编写本人的进一步的管制文件将必须参考该手册。

我察觉下定决心要做一件事，那就当然做失去。始终以来我都防止做 Packaging 方面进一步的钻研或者说学习，而是借助于更简便的路径来做散发（比方放在 GitHub Releases 你下载就好了），但简便或者就意味着用户的不简便，这就是最终我必须面对业余 Packaging 路径的起因。但既然做了一些钻研，那很容易就能发现一些资源就在那里，但没有人会刻意提醒你某些货色在哪里。怎么办呢？一般来说找到 usnet 这样的业余的新闻组，提出问题时失去有用批示的概率比拟大。但面向消费者的例如 quora 不见得是好抉择。我必须提醒的是，Discord 或者 dev.to 在面对我所介绍的这些无关 Packaging 的细碎问题也没有太多帮忙。当然，究竟你得借助于 Google 能力找到我所说的那些渠道，也包含那些有用的博文。同样地，我的，我想，对于有的人来说，这样的真正介绍到要点的文章也理当是会很有用的。

参考

• Debian 新维护者手册
• Debian Policy Manual
• Debian FAQ
• Building a Debian (.deb) source package, and publishing it on an Ubuntu PPA – Saverio Miroddi
• Creating and hosting your own deb packages and apt repo
• gpg-short-guide
• 从零开始制作 deb 文件