大家好啊，我是垫棍Shiroko，今天来点大家想看的东西。

这俩月一直在写一个叫做“ShiroDEB”的脚本集，觉得差不多了现在端上来水一下帖。

什么是ShiroDEB？

ShiroDEB是我为了减少软件打包过程中重复劳动而付出了更多劳动的一套脚本工具，核心思想来自Arch系的PKGBUILD，通过一系列预定义的步骤来产生软件包。一次编写，更新不愁（和CI更配喔）。

范例（SVG动画可能在某些浏览器上无法正常播放）：

为什么需要“构建脚本”

通常一个软件包的上游更新不会对其构建流程产生很大的影响，就算是二进制产物也不会有什么很大的变化，所以每次更新的流程几乎都是相同的。把这一部分内容固定下来，之后的更新基本上就是一个先改一下版本号，然后运行 shirodeb make的过程了。版本号甚至也可以自动获取～

这一方式的优点在于，可以使用构建服务器来自动触发打包的流程，实现软件包的自动更新（我暂时还没有开始搞CI部分）。同时，发布出去的构建脚本对于其他用户来讲也可以直接进行版本号的修改，然后构建出软件包，自己进行测试和使用。哪怕原始的构建脚本不能使用，也有一定的参考价值，也可以在此基础上干预一些编译参数，实现客制化。

栗：Remmina的构建脚本

自建库

目前ShiroDEB已经全面支持第三方自建库，从而摆脱UOS V20系统库版本过低的桎梏。通过在构建脚本中使用 export INGREDIENTS=("xxx")，即可在构建和打包过程中使用自建库而不是系统里面的自带依赖。脚本也会自动将运行时需要的库打包到软件包里，并处理相关的环境变量等。搭配szbt已经上传到依赖仓的自建库，更是可以直接使用而不需要打包进软件包内，减少了软件包的体积。

ShiroDEB也支持交互终端，提供给开发者一个方便使用自建库的途径。(如下图)

容器

ShiroDEB也支持使用bubblewrap来提供用户态容器层来实现对glibc等无法简单通过环境变量解决的二进制兼容～（目前这一部分还有待发掘）

其实理论上glibc可以通过patchelf修改rpath和interpreter和直接执行 ld.so来强制使用自定义的glibc，但是不知道为什么在UOS上不行，可能是我的姿势有些问题。

相关仓库

ShiroDEB：ShiroDEB主仓库
Recipes：Recipes是存放构建脚本的仓库
Ingredients：Ingredients是存放自建库和其他运行环境“配置方案”的脚本（二进制分发请关注SIG：deepin-shared-libs）

更为详细的使用说明在仓库的README中，如果感兴趣可以看一下～
（仍在开发阶段所以很多地方可能不完善，还请大家多多指教～）

前两个仓库在Gitee上也有镜像，请翻阅Spark Community Works Collections

希望有朝一日能变成另一个AUR（逃）

我会在11月的WHLUG上和大家互相交流学习，期待