变更日志包含每次变更的作者、修改内容、时间等信息
该控件包含包名称、维护者、构建依赖项等信息。
patch 目录包含包作者对上游代码所做的更改
Rules 是包的构建脚本
这些文件基本上是deb包的核心部分，也是我们以后对包进行修改时主要涉及到的部分。
首次成立
浏览完软件包的整体结构后，我们可以尝试改进软件包，但在此之前，我们首先需要安装它所需要的各种构建依赖项debian 源码编译，使用以下命令：
sudo apt build-dep node-pretty-ms
apt会根据包控制文件中的描述手动构建依赖，帮助我们安装所需的依赖。 下载安装完成后，使用debuild命令完成：
debuild -b -uc -us
命令运行完毕后，可以在上层目录中找到编译好的deb包。
修改源码
当然，我们这次的目标并不仅限于完整地重新编译deb包。 毕竟，如果是这样的话，为什么不直接从服务器下载呢？ 我们所要做的就是修改源代码并重新编译：
cd node-pretty-ms-7.0.1
vim index.js
放在
throw new TypeError('Expected a finite number');
变成
throw new TypeError('Expected a finite number!');
保存退出，使用以下命令编译日志
dch -i -Dunstable
这里的不稳定是指软件分发渠道，由于我们不是官方维护者，所以我们所做的修改将默认添加到*非维护者上传。 在这种情况下，我们需要在下一行中声明我们对源代码所做的更改：
编写变更日志后，您可以退出编辑器并使用以下命令生成补丁：
dpkg-source -b . --commit
输入补丁名称并确认，该命令还会将我们之前所做的更改保存到 debian/patches 目录中，并在编译源代码时手动应用。
完成上述修改后，使用以下命令重新生成dsc源码
dpkg-source -b .
再次回到上层目录，可以看到新生成的.dsc和debian.tar.xz文件。 这些是应用了我们之前的更改的新 deb 软件包。 重新编译只需回到源码子目录并重新输入：
debuild -b -uc -us
然后就坐下来等待包裹被领取吧！
先进方法
使用前面的形式直接编译其实很方便debian 源码编译，但是当我们大规模打包的时候就会出现问题：不同的包有不同的依赖关系，重复安装不仅特别麻烦，而且有时还可能会导致依赖关系估计不正确——显然not need 依赖的软件包就变成了必须依赖，这样你构建的软件包在本机上可能可以正常工作，但是放在别人的机器上却无法正常编译安装。 这就轮到pbuilder和sbuild了：这些工具可以帮助我们构建一个隔离的环境，类似于chroot或者docker，但是对于打包有更具体的优化，下面以pbuilder为例进行演示，
要安装 pbuilder，只需在终端中输入以下命令：
sudo apt install pbuilder
安装完成后，使用以下命令创建编译环境
sudo pbuilder create
这一步将为我们以后的编译配置一个完整的环境。 创建完成后，运行以下命令完成编译
pbuilder build node-pretty-ms_7.0.1-1.dsc
这是关于 deb 打包的简短教程。 至于pbuilder更高级的用法，有待读者进一步挖掘。
参考文章：
发表评论