deb 包是由软件 apt 包管理系统管理的的包, 常用于 Debian 系统的软件安装, pacman 系的系统无法直接安装 deb 包软件. 一般而言, 可以借助 debtap 这类工具来二次打包为 tar.zst 包, 再由 pacman 进行安装. 但是这种二次打包的方式并不为人所推荐, 即使是 debtap 的作者也不推荐利用这种方式来转包. 本文记录了笔者的一次转包过程 ( 结果是失败了 ), 探讨了这种转包方式的: 原理 / 可能遇到的问题 / 兼容性的处理
aTrust 是深信服的一款产品, 主要用于在电脑中建立公司的工作环境网络, 类似 openvpn, Linux 版本只提供了 deb 包
我的需求是在我的工作环境 Manjaro 系统中装上该软件
上图 ( 来源 ) 可见, 官方支持的 Linux 系统只有 UOS 和 麒麟, 而 UOS 来自于 deepin 魔改, 可见 deepin 也支持
DEBIAN
文件夹就是存放安装信息和安装脚本的地方control
记录了包信息postinst
/ postrm
等顾名思义是 hook, 里面是具体的脚本代码DEBIAN
文件夹里可以放置自定义 sh 脚本文件, 供给 hook 调用(others)
指待安装到系统的文件如 /opt/Something
/ /usr/bin/MyApp
等tar.zst: 该包
.PKGINFO
是存放安装信息.MTREE
我也不太理解, 请看这里.INSTALL
同样是脚本, 里面的代码结构描述了和上面 deb 包的 hook 脚本一样的钩子
(others)
指待安装到系统的文件如 /opt/Something
/ /usr/bin/MyApp
等
由上文可得知, 虽然两种打包系统的安装包文件结构不同, 但是总体的安装包的设计思路还是十分类似的:
debtap 可以帮我们直接把 deb 包转成一个模板化的 tar.zst 包, 即:
postins
脚本的代码注入进 .INSTALL
的 post_install
函数中 )这种方法的坑点如下:
DEBIAN
中的内置脚本. 例如有一种情况: DEBIAN
中写有自定义脚本 helpers.sh
, 钩子脚本 post_install
会调用这个 helpers.sh
来帮忙安装. 那么 debtap 在转的时候会无视这些自定义脚本, 统统不会打包进 tar.zst因此只要先用 debtap 把 deb 包初步转成 tar.zst 包, 再根据需求修改里面的 .INSTALL
代码, 理论上可以实现本次需求
这一步主要是查看源 deb 的打包脚本和取得 debtap 不会帮忙打包的冗余文件
然后获得文件夹 extract
, 里面就是源 deb 包的安装文件和脚本
利用 debtap 初步转包
过程中要求输入包名
debtap 会帮你分析出哪个依赖包你当前的系统不满足, 然后要求你编辑依赖信息, 你可以根据自己的需求进行删除
例如 aTrust 要求一个 deepin 的环境监测包 deepin-elf-verify
, 根据博文 deepin-elf-verify 究竟是何物? 可知 deepin-elf-verify
为空包, 于是直接从依赖中删掉
最终得到 tar.zst 包 aTrust.pkg.tar.zst
然后解开他: mkdir pkg && cp aTrust.tar.zst ./pkg && cd ./pkg && tar -I zstd -xvf aTrust.pkg.tar.zst
得到 tar.zst 的所有文件和脚本
分别对比 deb 包里和 tar.zst 包里的钩子脚本
首先发现 deb 的脚本中大量存在参数的获取, 例如脚本路径
但是 pacman 的安装是没有参数传递的, 因此需要改造, 这里我直接写死了路径:
同理, 所有的需要参数的地方都被我写死为具体的值
同时也发现了 deb 包中有几个 sh 脚本未被 debtap 打包进 tar.zst 中, 于是观察这些脚本被调用的方式, 发现是钩子直接调用了同级目录的脚本: sh -c ./xxx.sh
, 于是我把这些类似的调用都改成了 sh -c ~/Desktop/aTrust/sh/xxx.sh
这样的形式, 也就是固定他的调用路径, 然后把这些脚本放到桌面中: ~/Desktop/aTrust/sh/
, 然后给执行权限: chmod +x ~/Desktop/aTrust/sh/
重新打包 deb 包得到 atrust2.deb
再次转包
然后同样和上面一样也是删掉依赖: deepin-elf-verify
, 然后得到 aTrust2.pkg.tar.zst
, 安装:
结果和一开始相比果然有了变化:
但是从本质上来说, 和一开始比也没有不同: 同样无法启动代理. 这一点我看 aTrust 的日志以后, 发现直接原因是有一个 (登录) 服务没法启动, 这点与我在 Ubuntu22 上的实验结果完全一样 (Ubuntu22 上也没成功, 但 Ubuntu20 成功了)
最后推测原因可能有两个:
deepin-elf-verify
被删除了, Ubuntu22 也是装不上这个包, 原因是 openssl 的版本问题不过这些都是主观猜测, 没有任何证据
最后起了一个 Ubuntu20 的虚拟机, 在虚拟机上启动 aTrust 后, 利用 tinyproxy + microsocks 给 host 机输出一个代理端口
点击这里前往 Github 查看原文,交流意见~
文档信息
版权声明:自由转载 - 非商用 - 非衍生 - 保持署名(创意共享3.0许可证)