[...] Debian软件包的打包

[lumin]

制作deb软件包的过程很神奇（追溯细节会超级麻烦，比教育latex还要麻烦）。

在这里我以自己的玩具程序Bytefreq[0]来简要描述打包过程。
这里所有的步骤都遵循了官方文档maint-guide[1]

1. 下载源码，把原始源代码塞进tar.gz
2. 在源码目录下执行 dh_make，初始化 debian 子目录以及其内容
3. 删掉暂时不用的模板文件，修改8个 debian 子目录下的文件
其中尤其是 control, dirs , source/format,changelog 这几个文件
4. 修改妥当，在源码目录下执行
dpkg-buildpackage -us -uc
5. 这就完了。
你可以拷贝我的仓库之后直接 make deb-pkg 来自动打包，不过前提是
安装了海量debian helper/debian developer/debian maintainer脚本及程序。

对，这就结束了。我把maint-guide扫描了好几遍，打包实践了很多次，但依然不
知道“如何打包”。
这个过程里边有些神奇的地方：

1. control文件的Depends字段记录包依赖关系，然而仓库里的control文件该字段是
Depends: ${shlibs:Depends}, ${misc:Depends}
里边是两个占位符，在build-package过程中，某脚本施展黑魔法把占位符替
换掉，此处
bytefreq的依赖被自动解析为
Depends: libc6 (>= 2.2.5), libgomp1 (>= 4.9)
这绝对是黑魔法。
2. 打包用的脚本里有一大堆以 dh_* 命名，目测设计者旨在将打包过程分散到细
粒度的功能正交
脚本集合中。
3. Debian对上传的软件包要求相对严格（从打包麻烦程度就能看出来），
而且官方文档还吓唬人说 “一定要慎重检查你写在包里的东西，不然小心被
用户轰炸。。。”
评论略。

[0] github.com/cdluminate/bytefreq
这是个字节频率统计工具，功能不是很精简，而且有64位长整数溢出的bug
[1] anonscm.debian.org/cgit/ddp/maint-guide
Debian新维护者手册

[justzx]

可以看看这个教程：http://openyoudao.org/%E5%A6%82%E4%BD%95%E5%9C%A8ubuntu%E7%B3%BB%E7%BB%9F%E4%B8%8B%E5%88%B6%E4%BD%9C%E8%87%AA%E5%B7%B1%E7%9A%84ppa%E5%AE%89%E8%A3%85%E5%8C%85

--
您收到此邮件是因为您订阅了“西电开源社区”邮件列表。
要向此邮件列表发帖，请发送电子邮件至 xidian...@googlegroups.com。
要取消订阅，请发送电子邮件至 xidian_linux+unsubscribe@googlegroups.com。
请通过 https://groups.google.com/group/xidian_linux?hl=zh-CN 访问此网上论坛。
通过 [ipv6 enabled] http://xdlinux.info/ 或 http://xdl.in/
    [ipv4 only] http://linux.xidian.edu.cn/
     [手机]：http://m.xdlinux.info/   访问西电开源社区。
--- 您收到此邮件是因为您订阅了 Google 网上论坛的“西电开源社区邮件列表”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到xidian_linux+unsubscribe@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。

--

http://openyoudao.org/

[lumin]

前辈的打包过程有问题。

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
   [s/i/m/l/k/n] s

Github显示openyoudao由python（97%）和shell script（3%）编写完成，
显然平台独立。（indep）
选s无伤大雅。

不过关键在于debian/control文件的
Architecture:
字段应当填写all，不然填any会自动打包出来是 package_version_$(arch).deb，
对于Ubuntu还好，Ubuntu默认给dpkg开了multi-arch，但Debian不开。
填写all自动打包出来就是package_version_all.deb

根据前辈的发布源可以看到
https://launchpad.net/~justzx2011/+archive/ubuntu/openyoudao-v0.2/+packages

• openyoudao_0.2-1ubuntu1_amd64.deb (149.1 KiB)
• openyoudao_0.2-1ubuntu1_i386.deb (149.1 KiB)

明显填的是any，于是buildd分别给amd64和i386构造了软件包。

我想说还好是ubuntu，如果给debian那么会变成

openyoudao_0.2-1_amd64.deb
openyoudao_0.2-1_arm64.deb
openyoudao_0.2-1_armel.deb
openyoudao_0.2-1_armhf.deb
openyoudao_0.2-1_i386.deb
openyoudao_0.2-1_kfreebsd-amd64.deb
openyoudao_0.2-1_kfreebsd-i386.deb
openyoudao_0.2-1_mips.deb
openyoudao_0.2-1_mipsel.deb
openyoudao_0.2-1_powerpc.deb
openyoudao_0.2-1_ppc64el.deb
openyoudao_0.2-1_s390x.deb

。。。超级尴尬。
python脚本而已。

On 26/02/15 02:30, justzx wrote:

可以看看这个教程：http://openyoudao.org/%E5%A6%82%E4%BD%95%E5%9C%A8ubuntu%E7%B3%BB%E7%BB%9F%E4%B8%8B%E5%88%B6%E4%BD%9C%E8%87%AA%E5%B7%B1%E7%9A%84ppa%E5%AE%89%E8%A3%85%E5%8C%85

[lumin]

补一句，关于deb打包，这里的文档才是基础，
ubuntu的文档非常多的细节都引用到debian去了。

https://www.debian.org/doc/

不必递归阅读。

另外，dpkg的文档没有关于deb的详细技术细节。

[Zhang Cheng]

2015-02-26 19:48 GMT+08:00 lumin <cdlum...@163.com>:

​Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
[s/i/m/l/k/n] s​

​这个问题，从字面很好理解，如果只有一个二进制文件的包，那么选s，如果有多个二进制文件（例如​binutils）选m，如果是架构无关的二进制文件（脚本）选i。不过我个人认为这个选项现在已经没有什么实际的作用了，随便选是没有问题的。

不过关键在于debian/control文件的
Architecture:
字段应当填写all，不然填any会自动打包出来是 package_version_$(arch).deb，
对于Ubuntu还好，Ubuntu默认给dpkg开了multi-arch，但Debian不开。
填写all自动打包出来就是package_version_all.deb

​这里Architecture跟Multi-Arch完全没有关系。Multi-Arch​的作用是可以在一个系统里同时安装不同架构的库文件（以及二进制文件）。关于Multi-Arch，可以看我前不久在另一个列表里发的邮件：https://archive.lug.ustc.edu.cn/2015-February/019614.html

这里的Architecture，准确的理解应该是”这个包可以在哪些架构上运行“，它可以是一个列表，也支持一些特殊的语法，这里举一些列子：

* all：表示可以在所有架构上运行，并且没有差别。一般纯脚本类的、文档类的包都写all

* any：表示可以在所有架构上运行，但是需要分别编译，其二进制文件不同

* linux-any：debian有多种内核，目前有GNU/Linux内核、GNU/kFreeBSD内核、netbsd等，似乎还有人在移植minix内核。开个玩笑，如果不考虑版权问题的话，甚至会出现Debian MS/NTKernel的port。

* any-i386, any-amd64：表示可以在任意内核、i386/amd64架构上运行（grub-efi的Architecture字段就是这个样子的）

* i386 kopensolaris-i386 any-amd64：（grub-efi-amd64-bin的Architecture字段如是），这表示可以在linux内核+i386、opensolaris内核+i386以及任意内核+amd64的平台上运行

更多的例子不再举例了。

这个字段可以认为是”建议build farm为这些平台构建deb包“，但是否真的会打包，还是由build farm来决定的（ubuntu的打包平台叫build farm，debian的打包集群跑的是buildd）。

具体到实际情况中，能填All的包总是填all，能填any的包总是填any，只有当不支持某些平台时，再根据实际情况指定。

--

Cheng,

Best Regards

[lumin]

这里我说话跳跃了，
由于填的是any，那么在ubuntu默认开启multi-arch的条件下，
用户随便装生成的amd64包或者i386包都碰巧能干活。

新手用户有一定的可能把i386包往amd64 OS上装。

On 26/02/15 14:30, Zhang Cheng wrote:

​ 这里Architecture跟Multi-Arch完全没有关系。Multi-Arch​的作用是可以在一个系统里同时安装不同架构的 库文件（以及二进制文件）。关于Multi-Arch，可以看我前不久在另一个列表里发的邮件：https://archive.lug.ustc.edu.cn/2015-February/019614.html

[justzx]

由于程序用python写的，打包过程中，一直没碰到这个问题，这个可以再完善一些

--
您收到此邮件是因为您订阅了“西电开源社区”邮件列表。
要向此邮件列表发帖，请发送电子邮件至 xidian...@googlegroups.com。

要取消订阅，请发送电子邮件至 xidian_linux...@googlegroups.com。

请通过 https://groups.google.com/group/xidian_linux?hl=zh-CN 访问此网上论坛。
通过 [ipv6 enabled] http://xdlinux.info/ 或 http://xdl.in/
[ipv4 only] http://linux.xidian.edu.cn/
[手机]：http://m.xdlinux.info/
访问西电开源社区。
---

您收到此邮件是因为您订阅了Google网上论坛上的“西电开源社区邮件列表”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到xidian_linux...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

http://openyoudao.org/

[lumin]

这里有处蹊跷。

官方文档原文是 single binary package，这个复合词有歧义：
1. a package which contains only a single binary file.
2. a single package which contains binary content.

根据maint-guide的阐述，2应该才是正解：
由单一源码包生成的一个二进制包。

分清这些定义并非没有任何实际作用，毕竟 dh_make 命令让用户选择
软件包类型，就是为了生成相应的模板，减少人类的工作量。
即便选错也可以手工修改到合适状态，但是比机器生成麻烦多。

典型影响文件debian/control。
这里我用 debian glibc 的control 文件作为一个极端的
(复合(multi)二进制包)例子来展示：
(旨在说明能避免hard code就避免)

$ cat control | grep Package
Package: libc-bin
Package: libc-dev-bin
Package: glibc-doc
Package: glibc-source
Package: locales
Package: locales-all
Package: nscd
Package: multiarch-support
Package: libc6
Package: libc6-dev
Package: libc6-dbg
Package: libc6-pic
Package: libc6-udeb
XC-Package-Type: udeb
Package: libc6.1
Package: libc6.1-dev
Package: libc6.1-dbg
Package: libc6.1-pic
Package: libc6.1-udeb
XC-Package-Type: udeb
Package: libc0.3
Package: libc0.3-dev
Package: libc0.3-dbg
Package: libc0.3-pic
Package: libc0.3-udeb
XC-Package-Type: udeb
Package: libc0.1
Package: libc0.1-dev
Package: libc0.1-dbg
Package: libc0.1-pic
Package: libc0.1-udeb
XC-Package-Type: udeb
Package: libc6-i386
Package: libc6-dev-i386
Package: libc6-sparc
Package: libc6-dev-sparc
Package: libc6-sparc64
Package: libc6-dev-sparc64
Package: libc6-s390
Package: libc6-dev-s390
Package: libc6-amd64
Package: libc6-dev-amd64
Package: libc6-powerpc
Package: libc6-dev-powerpc
Package: libc6-ppc64
Package: libc6-dev-ppc64
Package: libc6-mips32
Package: libc6-dev-mips32
Package: libc6-mipsn32
Package: libc6-dev-mipsn32
Package: libc6-mips64
Package: libc6-dev-mips64
Package: libc0.1-i386
Package: libc0.1-dev-i386
Package: libc6-x32
Package: libc6-dev-x32
Package: libc6-i686
Package: libc6-xen
Package: libc0.1-i686
Package: libc0.3-i686
Package: libc0.3-xen
Package: libc6.1-alphaev67
Package: libc6-loongson2f
Package: libnss-dns-udeb
XC-Package-Type: udeb
Package: libnss-files-udeb
XC-Package-Type: udeb

我自己作了一些验证，[s/i/m/l/k/n] 单单是在 control 文件模板上就有非常多
细节上的不同。
比如自动添加的依赖。

On 26/02/15 14:30, Zhang Cheng wrote:

> 这个问题，从字面很好理解，如果只有一个二进制文件的包，那么选s，如果有
> 多个二进制文件（例如​ binutils）选m，如果是架构无关的二进制文件（脚
> 本）选i。不过我个人认为这个选项现在已经没有什么实际的作用了，随便选是
> 没有问题 的。

[Zhang Cheng]

2015-03-01 8:37 GMT+08:00 lumin <cdlum...@163.com>:

我自己作了一些验证，[s/i/m/l/k/n] 单单是在 control 文件模板上就有非常多 细节上的不同。
比如自动添加的依赖。

​也就是说这个选项仅仅影响dh_make的行为（生成debian/control文件时选用的模板不同），对于包的本质没有影响。我除了初学时使用过dh_make，后来打包无数，一直没有用过dh_make，所以没有注意过这个选项的含义。

debian下还有许多包，debian/control不是手写的，而是生成的，最极端的例子是linux（内核）这个包，这类包基本上不可能也不需要用dh_make来初始化环境了。​

--

Cheng,

Best Regards

[lumin]

yes.

这个选项的确是让dh-make来选择合适的模板。
而对软件包的本质没有影响。

可以参考我今天在 devel 上的提问：
https://lists.debian.org/debian-devel/2015/03/msg00002.html

可以从软件包 dh-make 的文件列表中看出明显的模板库：

$ dpkg -L dh-make
/usr/share/debhelper/dh_make/debiank
/usr/share/debhelper/dh_make/debiank/package-modules-_KVERS_.postinst.modules.in.ex
/usr/share/debhelper/dh_make/debiank/README.Debian
/usr/share/debhelper/dh_make/debiank/rules.old
/usr/share/debhelper/dh_make/debiank/control
/usr/share/debhelper/dh_make/debiank/rules.dh7
/usr/share/debhelper/dh_make/debiank/control.modules.in
/usr/share/debhelper/dh_make/debians
/usr/share/debhelper/dh_make/debians/rules.cdbs
/usr/share/debhelper/dh_make/debians/watch.ex
/usr/share/debhelper/dh_make/debians/rules.old
/usr/share/debhelper/dh_make/debians/control
/usr/share/debhelper/dh_make/debians/rules.dh7
/usr/share/debhelper/dh_make/debianm
/usr/share/debhelper/dh_make/debianm/watch.ex
/usr/share/debhelper/dh_make/debianm/rules.old
/usr/share/debhelper/dh_make/debianm/control
/usr/share/debhelper/dh_make/debianm/package-doc.install
/usr/share/debhelper/dh_make/debianm/rules.dh7
/usr/share/debhelper/dh_make/debianm/package-doc.docs
/usr/share/debhelper/dh_make/debiann
/usr/share/debhelper/dh_make/debiann/README.Debian
/usr/share/debhelper/dh_make/debiann/kpatches
/usr/share/debhelper/dh_make/debiann/rules.old
/usr/share/debhelper/dh_make/debiann/control
/usr/share/debhelper/dh_make/debiann/rules.dh7
/usr/share/debhelper/dh_make/debiani
/usr/share/debhelper/dh_make/debiani/watch.ex
/usr/share/debhelper/dh_make/debiani/rules.old
/usr/share/debhelper/dh_make/debiani/control
/usr/share/debhelper/dh_make/debiani/rules.dh7
/usr/share/debhelper/dh_make/emacs
/usr/share/debhelper/dh_make/emacs/emacsen-remove.ex
/usr/share/debhelper/dh_make/emacs/emacsen-startup.ex
/usr/share/debhelper/dh_make/emacs/emacsen-install.ex
/usr/share/debhelper/dh_make/licenses
/usr/share/debhelper/dh_make/licenses/apache
/usr/share/debhelper/dh_make/licenses/mit
/usr/share/debhelper/dh_make/licenses/gpl3
/usr/share/debhelper/dh_make/licenses/lgpl3
/usr/share/debhelper/dh_make/licenses/lgpl2
/usr/share/debhelper/dh_make/licenses/bsd
/usr/share/debhelper/dh_make/licenses/blank
/usr/share/debhelper/dh_make/licenses/gpl2
/usr/share/debhelper/dh_make/licenses/artistic
/usr/share/debhelper/dh_make/debianl
/usr/share/debhelper/dh_make/debianl/package-dev.dirs
/usr/share/debhelper/dh_make/debianl/watch.ex
/usr/share/debhelper/dh_make/debianl/shlibs.local.ex
/usr/share/debhelper/dh_make/debianl/package1.install
/usr/share/debhelper/dh_make/debianl/rules.old
/usr/share/debhelper/dh_make/debianl/package1.dirs
/usr/share/debhelper/dh_make/debianl/control
/usr/share/debhelper/dh_make/debianl/package-dev.install
/usr/share/debhelper/dh_make/debianl/rules.dh7


On 01/03/15 03:49, Zhang Cheng wrote:
> ​也就是说这个选项仅仅影响dh_make的行为（生成debian/control文件时选用的
> 模板不同），对于 包的本质没有影响。