deb软件包结构分析

2023年12月6日发(作者：)

deb软件包结构分析

释放软件包

方法1、

ar

-t 查看deb包存档格式文件

-x 释放存档文件

Debian 包的ar 存档格式由三个文件组成：

Debian-binary: 存档格式的版本

Control文件：deb包的DEBIAN目录控制信息，这些脚本在软件包处理的不同的阶段被dpkg调用

Data文件：deb包的数据信息，存档文件，执行文件等

后面两个文件的压缩格式各种各样。这边不讨论。

方法2、

Dpkg

-x 解压程序文件

-X 解压程序文件（输出的标准输出）

-e 解压控制文件

软件包元信息

Debian 软件包不仅仅只是一些待安装的文件的存档，它是一个更大的结构的一部分，它描述与其它Debian 软件包的关系（依赖、

冲突、建议）。它还提供脚本供软件包的生命周期的不同阶段（安装、删除、升级）使用。这些供包管理工具使用的数据不是被打

包的软件的一部分，但它们存在于软件包里，被称作“元信息”（关于其它信息的信息）。

1、control文件

Apt-cache工具show出的gcc的信息，这个推测是control文件中的内容

下面这个是cat出的sogoupinyin_1.2.0.0042_软件包的control信息。

语法：field: value

如果是多行value，需要空一个空格

字段分析：

1）、源码包中有control文件【debian/control】

Source (mandatory)

Maintainer (mandatory)

Uploaders

Section (recommended)

Priority (recommended)

Build-Depends et al

Standards-Version (recommended)

Homepage

Vcs-Browser, Vcs-Git, et al.

2）、二进制包中有control文件【DEBIAN/control】?Package (mandatory)

Source

Version (mandatory)

Section (recommended)

Priority (recommended)

Architecture (mandatory)Essential

Depends

Installed-Size

Maintainer (mandatory)

Description (mandatory)

Homepage

Built-Using

3）、

(强制的) 源码包的名字

e(强制的) 二进制包的名字

Package names (both source and binary, see ‘Package’on the next page) must

consist only of lower case letters (a-z),digits (0-9), plus (+) and minus (-) signs, and

periods (.). They must be at least two characters long and must start withan

alphanumeric character.

iner(mandatory) 维护者

维护者的名字在前面，后面用“<>”写上电子邮箱地址。

ers 维护者

可选的字段，如果Maintainer只写了一个团队或者是一个团队的公共邮箱，那么这一字段可以写维护者（人）的名字和邮箱，语法和

Maintainer字段一样。

d-By 维护者

对这个版本的软件包修改过的维护者。格式同Maintainer字段。

n 节/部分

这个字段指出软件包被维护者所分属的应用领域。目前，这个字段可以有下面这些关键字：

At present, they are: admin, cli-mono, comm,database, debug, devel, doc, editors, education, electronics, embedded, fonts, games,

gnome, gnu-r, gnustep, graphics,hamradio, haskell, httpd, interpreters, introspection, java, kde, kernel, libdevel, libs, lisp,

localization, mail, math, metapackages,misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound,

tasks, tex, text, utils, vcs,video, web, x11, xfce, zope.

ties 优先级

这个字段标识软件包的优先级别，是维护者指定的优先级，在Debian系统中表示软件包的一种等级划分。在debian/control文件中，

这个字段的的值应该和.change文件中的值一致。

在目前的体系中，优先级分为五个等级：

Required：这个优先级的软件包对于系统来说是必须的（dpkg功能是依赖这些软件包的）。移除required等级的软件包可能造成系

统的破坏、无法运行，而且你还不能用dpkg返回刚刚的操作，所以除非你知道自己在做什么。

Important：这个优先级的软件包是一些系统日常必备的东西，如果系统不具备这些软件，系统运行会非常不爽，让人无法接受，但

这个优先级的软件不能太大，如VIM等。所以说是小的、必要的一些工具。

Standard：这个优先级是一些缺省安装的软件包，这些软件包足够小，不一定只是工作在命令行下的，它不能包含一些大的软件。

Optional：（在定义中，非required即为optional，但在这里不是），这个优先

级的很多软件你想安装但是你也不是特别的强烈需要这些软件。这个级别软件很多，想X-window系统、TeX等应用。Optional包不

允许互相之间有冲突。

Extra：不是required、important、standard、optional优先级的包都是这个优先级，这些包可能互相冲突（包括其他优先级），要安

装的话除非你知道这些包是干什么用的。ecture 架构

取决于（依赖）上下文和control文件，该字段包含下面的四种格式：

1、一个独特的单词（os-arch）指出适用的机器架构，os常常省略

2、用通配符标识机器架构，“any”表示匹配所有的架构且常用

3、“all”标识独立于机器架构的包

4、“source”标识一个源代码包

在终端使用“dpkg-architecture -L”命令查看os-arch有哪些值，看到有349个值

注：

在源码包的debian/control文件中，该字段可以包含“all”、“any”、或是os-arch，他们之间空格间隔。如果是出现“all”或者“any”，该值

必须是全部部分，即只能有all或者any独立存在。大部分的包是“all”或“any”。

指定的一个特定的os-arch架构list，则源码包将会建立一个依赖list表中架构的包。

在Debian源码控制文件.dsc文件中，该字段包含一个architecture list和架构的通配符，中间用空格隔开。当字段中包含通配符any

时，只能同时存在all。

源码包中只有“any”通配符，表示源码包不依赖于任何特定的架构，能编译适应任意架构的。能生成特定于当前体系的二进制包。

源码包中只有“all”通配符，表示源码包仅仅生成独立于体系结构的包。

源码包有“any”和“all”通配符，表示不依赖于任何特定的架构，生成的二进制包集合中包含至少一个依赖一种体系的包和一个独立于

体系架构的包。

在.changes文件中Architecture字段列出的是目前升级后的包对应的Architecture。如果源码包也升级了，特殊值“source”还是应该存

在的。任意的独立于架构的包升级后“all”值也存在。架构通配符像“any”这些东西绝对不能出现在.changes文件的Architecture字段

中。

ial 重要

这是一个布尔变量的字段，yes|no，改变量只可能存在于二进制的包中，如果值是yes，则软件包管理系统则不能删除这个包（只能

升级或者是取代）。如果值为no，可以省略不写。

e interrelationship fields 依赖

这个字段描述的是软件包和其他软件包的关系。Depends, Pre-Depends,

Recommends, Suggests,Breaks, Conflicts, Provides, Replaces, Enhances

rds-Version 标准版本

最近的符合标准（政策文档和相关文档）的包。

n 版本

软件包的版本号。

ption 描述

在源代码包和二进制的control文件中都存在这个字段，它是对软件包的描述，包含两个部分，一个简洁和一个大段描述。这个一个

多行的字段，格式如下：Description:

在extended description的部分每行必须以空格开头。 二进制文件

这个字段列出二进制软件包。它的语法和意义根据出现在不同的control文件而不同。

在.dsc文件中，列出源码包所能生成的二进制包，用逗号隔开。

在.changes文件中，列出uploaded的二进制包，用空格隔开。

led-Size 安装后大小

这个字段出现在二进制包的control文件和Packages（软件仓库中包索引文件）文件中。它给出了一个估计的磁盘空间大小。实际的

安装大小可能基于块大小、文件系统属性、安装包脚本处理等因素而变化。

文件

该字段包含的是文件信息的列表。语法根据不同的背景而不同。

这是个多行的字段，Files字段值之后是空的（Files：）。之后每行一个文件，每行都需要空格缩进，并且有空格分隔的多个子字段

组成。

在.dsc文件中，包含MD5校验和字段，size字段和filename字段：Files:

c6f698f19f2a2aa07dbb9bbda90a2754 571925 example_

938512f08422f3509ff36f125f5873ba 6220 example_ 在.changes文件中，每行包含一个uploaded的文件，包含MD5检

验和字段，size字段，section字段，priority字段和filename字段：

Files:

4c31ab7bfc40d3cf49d78 1428 text extra example_

c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_

938512f08422f3509ff36f125f5873ba 6220 text extra example_

7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_

ge 主页

该安装包的URL站点，最好是有该软件包的原始资源和额外的信息文档，这个字段只是个简单的URL，没有其他的字符如<>。

ums-Shal and Checksums-Sha256

这是两个多行的字段，都是包含校验和、文件大小的文件列表。两个语法是相同的，不同之处在于其算法不同，Checksums-Sha1

采用SHA-1算法，

Checksums-Sha256采用SHA256算法。

这个字段列出的文件必须和Files字段列出的文件一一对应。

n Control System (VCS) fields 版本控制系统（模糊的概念）

Debian source packages通过VCSs日益发展壮大。一下字段的目的是表明公开可获得的仓库的发展。

Vcs-Browser 仓库的web界面URL

Vcs-Arch, Vcs-Bzr (Bazaar), Vcs-Cvs, Vcs-Darcs, Vcs-Git, Vcs-Hg (Mercurial), Vcs-Mtn (Monotone), Vcs-Svn (Subversion)

字段名标识VCS。字段值使用版本控制系统的传统语法来描述存储仓库的位置，也足够定位打包软件仓库的位置。

e-List

多行字段，列出源码包能生成的软件包，包括每一个架构的软件包。

没一行包含name、type、section、priority，中间用空格间隔。e-Type

简单的一个单词用来表明软件包类型：deb表明是二进制软件包，udeb表明是微小的二进制软件包

xxii.

2、依赖性declaring relationships between packages

语法：

这些字段的语法是统一的。都是一个安装包名字的列表，中间用逗号隔开。

Depends,Recommends,Suggests,Pre-Depends,Build-Depends and Build-Depends-Indep 这几个字段中，可能有可选项，中间使

用| 隔开，这种情况下，随便哪个包都可以满足依赖性。

依赖关系允许使用<<, <=, =, >=, >>，这些符号用来表示小于，小于等于，等于，大于等于，大于的关系。这里不能使用< 和> 来表示

关系。

为保持一致性一般建议这么做，在版本关系前需要一个空格，在版本号后需要一个空格，每个逗号之后需要一个空格，在“|”符号两

边都需要空格，还有每个左括号之前。

Package: mutt

Version: 1.3.17-1

Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

对于build relationship系列（Build-Depends, Build-Depends-Indep, Build-Conflicts and Build-Conflicts-Indep）如果当前主机架构

不在列表中并且没有！标记，或者有预感叹号，包名和相关的版本是目的性的忽略的。

Source: glibc

Build-Depends-Indep: texinfo

Build-Depends: kernel-headers-2.2.10 [!hurd-i386],

hurd-dev [hurd-i386], gnumach-dev [hurd-i386]

上面这个例子意思是需要kernel-headers-2.2.10的所有架构而不需要hurd-i386架构，hurd-dev和gnumach-dev仅仅需要hurd-i386架

构版本就可以了。

依赖项：

Depends：这个声明是绝对依赖的。一个安装包如果没有将Depends中列出的安装包正确配置，则这个安装包的配置项不能进行配

置（能解包不能配置）。

该字段的依赖包为安装包提供大量的功能。

该字段为postinst脚本或者prerm脚本的运行提供了依赖。

当postrm脚本运行清理安装包的时候，该字段也会被用到，这个时候并不会保证这些依赖项的可获得性，但是最好是可获得的。如

果这些依赖项不满足也没关

系，postrm脚本会跳过这个动作。

Recommends：强烈依赖，但是不是必须要求的依赖项。

Suggests：这个字段用来声明一个更好用的安装包。用这个字段告诉包管理系统和用户，这些列出的包能加强软件的可用性，当然

不安装这些依赖项软件也是能完美运行的。

Enhances：这个字段和Suggests字段差不多，但是作用刚好相反。声明这个安装包能增强哪些软件的功能。

Pre-Depends：这个字段类似Depends字段，不同之处在于它强制dpkg在安装包开始安装之前就要完全安装这些依赖项（这写依赖

项不满足的话都不能进行解包）。

以上的五个依赖性等级，你应该根据需要声明的软件包对软件包的重要性来决定要选择依赖性的等级。

Breaks：当一个二进制包声明Breaks另一个，dpkg将会拒绝在Breaks中声明的包进行解包，除非被破坏的包是第一次提取，并且拒

绝被破坏包的重新配置。

它标志着一个包的安装会将另外一个包（或者是特定版本）中断掉。通常而言，两个包之间的不兼容是短暂的，中断关系会特别指

出那些不兼容的版本。（这个不太明白）Conflicts：这个字段声明的安装包，dpkg将会拒绝在系统中同时对他们解包。如果一个包被解包，另一个包必须首先卸载掉。如果被解包的包标记未replacing，则系统上的另一个、或者说是另一个被标记为

deselected、或者两个包都被标记未Essential，dpkg将会自动的移除造成冲突的那个包。否则会安装失败。

Provides：软件包包含了其他某些软件包，软件包提供了某些软件包的实现的功能。

Replaces：该字段声明的包会覆盖某些文件，或者完全取代另一个包。Replaces控制字段有两个不同的目的。

1、覆盖另一个包的一些文件

2、取代整个包，强制删除

3、conffiles文件

最令人气愤的就是当你花费了大量的时间和精力去自定义一个软件的配置程序，却仅仅被一个小小的升级就破坏了你曾经做出的修

改。Coffiles文件包含有关软件包配置文件的信息。

Conffiles文件的作用就是在软件升级的时候，dpkg对这些文件做特殊的对待，系统会问你是否保存配置文件。如果不想被修改就把

这些配置文件写到conffiles文件中。

所以这些还是根据需要添加吧。

4、Copyright

每个软件包必须包含版权信息和发布证件，这些东西应该写在/usr/share/doc/package/copyright文件中。该文件会被安装

到/usr/share/doc/package目录下或者是其他合适的目录下面。

5、

不是Debian-native的软件包必须包含/usr/share/doc/package/的压缩文件，该文件是复制相对应源码包的

debian/changelog文件压缩而成的。

如果上游的changelog文件可获得，则软件包中应为的纯文本文件。如果上游的changelog是以html格式发布的，则软

件包中应该为格式。如果上游只有一个单独的维护者（maintainer），没有changelog的更新日志，则debian的

changelog 文件命名为格式。

6、Md5sums

这个文件保存这软件包中各个文件的md5校验值，用来检测软件包的完整性。

可以用下面这条命令生成md5sums文件

7、软件的维护者脚本

一个软件包可能会提供一些脚本给软件管理系统（dpkg）使用，用于软件的安装、升级、卸载。另外，这些维护者脚本都是可选

的。

这些脚本是控制信息文件preinst, postinst, prerm 和postrm，这些文件都是以为#！而开头的。这些文件的执行权限是755,即所有用户

都有读和执行的权限，但是只有root用户有写的权限。

Preinst：Ddbian软件包解压之前需要执行的脚本，为正在被升级的包停止相关服务，直到升级或安装完成。

Postinst：主要完成软件包安装完成后的配置工作。通常postinst脚本要求用户输入，和/或警告用户如果接受默认值，应该记得按照

要求返回重新配置这个软件。一个软件包安装或升级完成后，postinst脚本驱动命令，启动或重启相应的服务。

Prerm：停止一个软件包的相关进程，要卸载软件包的相关文件前执行。

Postrm：修改相关文件或链接，和/或卸载软件包所创建的文件。

当前系统中的所有配置文件都可以在/var/lib/dpkg/info目录下找到。

8、rules文件

rules必须是一个可执行文件(0755)，而且rules必须以#!/usr/bin/make -f 开头，这和写脚本是一样的。

Debian/rules文件本质上是一个Makefile文件，这个Makefile文件定义了创建deb格式软件包的规则。打包工具按照rules文件指定的

规则，完成编译，将软件安装到临时安装目录，清理编译目录等操作，并依据安装到临时目录的文件来生成deb格式的软件包。

写rules文件至少要懂一些debhelper的相关知识。

[1]/doc/ /doc/debian-policy/[2]/doc/ /browse/zh-CN/stable/[3]/doc/ /doc/manuals/maint-guide/