前一阵子，某Q群里的某初中生居然跳上了Fedora这辆灵车，还一直缠着我要我给他整个打rpm包的教程，说什么要复兴FedoraCN之类的我听不懂的话。碰巧听说Fedora似乎还没有wechat-uos，于是我就寻思着给Fedora打一个，顺便熟悉一下dnf的操作。
事实上，Fedora和Archlinux的目录结构很相似，理论上来讲Archlinux的大部分包都可以直接解压后塞到Fedora里直接用，对于咱这种日常偷Deb包的Arch用户来说基本没什么难度，唯一的难点在于处理依赖关系。
Tips1: 使用电脑端的访客可以在页面左下角打开侧栏以获取目录。
下载链接#
如果你是为了wechat-uos这个包而非教程而来的，下载链接在这里。https://zhullyb.lanzoui.com/ikN55rqr7ah
偷包环境#
- Archlinux实体机(打包)
- Fedora虚拟机(依赖查询、测试)
准备好wechat-uos#
首先，咱们先在Archlinux上把我们的wechat-uos先打包好，这个老生常谈的问题我不多赘述了。
yay -S wechat-uos --noconfirm
查找wechat-uos在Archlinux上所需的依赖#
再去查看wechat-uos所需要的依赖
[zhullyb@Archlinux ~]$ yay -Si wechat-uos
:: Querying AUR...
Repository : aur
Name : wechat-uos
Keywords : electron patched uos wechat weixin
Version : 2:2.0.0-1145141919
Description : UOS专业版微信 (迫真魔改版)
URL : https://www.chinauos.com/resource/download-professional
AUR URL : https://aur.archlinux.org/packages/wechat-uos
Groups : None
Licenses : MIT
Provides : None
Depends On : gtk2 gtk3 libxss gconf nss lsb-release bubblewrap
Make Deps : imagemagick
Check Deps : None
Optional Deps : None
Conflicts With : None
Maintainer : DuckSoft
Votes : 16
Popularity : 0.603501
First Submitted : Wed 30 Dec 2020 12:21:51 PM CST
Last Modified : Sat 20 Feb 2021 06:53:24 AM CST
Out-of-date : No
查找Fedora上的对应依赖包名#
然后我们需要去Fedora上找一找这些依赖在Fedora上的包名都叫什么。
比如这个bubblewrap，我们需要的是他提供的bwrap，所以我们直接在Fedora上sudo dnf provides bwrap
再比如gconf并没有在/usr/bin路径下直接留下什么非常具有代表性的可执行文件，所以在Fedora里面寻找等效包就稍微复杂一些，但也并非不能找。
先在Archlinux下使用pacman -Ql gconf，输出结果有点长，我就截一小段上来。
[zhullyb@Archlinux ~]$ pacman -Qlq gconf
/etc/
/etc/gconf/
/etc/gconf/2/
/etc/gconf/2/evoldap.conf
/etc/gconf/2/path
/etc/gconf/gconf.xml.defaults/
/etc/gconf/gconf.xml.mandatory/
/etc/gconf/gconf.xml.system/
/etc/xdg/
/etc/xdg/autostart/
/etc/xdg/autostart/gsettings-data-convert.desktop
/usr/
/usr/bin/
/usr/bin/gconf-merge-schema
/usr/bin/gconf-merge-tree
/usr/bin/gconfpkg
/usr/bin/gconftool-2
......
可以发现，gconf还是有不少文件是非常具有代表性的，比如这里的/usr/bin/gconf-merge-tree，我们在Fedora上使用sudo dnf provides gconf-merge-tree很容易就能找到对应的包是GConf2。
lsb-release这个依赖中，我们只是需要/etc/lsb-release这个文件存在让我们的bwrap可以顺利地伪装成uos的样子。Fedora中虽然有redhat-lsb-core这个包算是lsb-release的等效包，但是并不提供这个文件，因此我们只需要在待会儿打包的时候带一个/etc/lsb-release的空文件即可，不需要将redhat-lsb-core写进依赖。
最终我们可以确定下来需要的依赖为gtk2,gtk3,libXScrnSaver,nss,bubblewrap,GConf2。
准备打包#
安装rpm-tools#
sudo pacman -S rpm-tools
生成工作路径#
mkdir -pv $HOME/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
编写 spec 文件#
Name: wechat-uos
Version: 2.0.0
Release: 1
Summary: A wechat client based on electron.
License: None
URL: https://www.chinauos.com/resource/download-professional
Packager: zhullyb
Requires: gtk2,gtk3,libXScrnSaver,nss,bubblewrap,GConf2
AutoReqProv: no
%description
%prep
%pre
%post
%preun
%postun
%files
/etc/lsb-release
/opt/wechat-uos/
/usr/bin/wechat-uos
/usr/lib/license/libuosdevicea.so
/usr/share/applications/wechat-uos.desktop
/usr/share/icons/hicolor/128x128/apps/wechat.png
/usr/share/icons/hicolor/16x16/apps/wechat.png
/usr/share/icons/hicolor/256x256/apps/wechat.png
/usr/share/icons/hicolor/48x48/apps/wechat.png
/usr/share/icons/hicolor/64x64/apps/wechat.png
处理source#
一般来说，我们需要配置各种奇奇怪怪的编译命令，但是我这里直接选择了打包二进制文件，一来是减少了对于spec的学习成本，二来是因为wechat-uos本来就不开源，也没什么好编译的。
创建我们wechat-uos的二进制文件所需要放入的文件夹。
mkdir $HOME/rpmbuild/BUILDROOT/wechat-uos-2.0.0-1.x86_64
将我们的wechat-uos直接放入对应的文件夹中
解压原先打包好的wechat-uos
补上我们的/etc/lsb-release
mkdir $HOME/rpmbuild/BUILDROOT/wechat-uos-2.0.0-1.x86_64/etc/
touch $HOME/rpmbuild/BUILDROOT/wechat-uos-2.0.0-1.x86_64/etc/lsb-release
正式打包#
rpmbuild -bb --target=x86_64 SPECS/wechat-uos.spec --nodeps
打包成功
安装测试#
sudo dnf install ./wechat-uos-2.0.0-1.x86_64.rpm
测试通过
写在最后#
rpm的打包工具是我近期最想吐槽的东西了，主要槽点有两个。
其一是：rpm在打包时的默认状态下，会使用 file 命令判断文件，如果是二进制的，用ldd判断依赖；如果是脚本，过滤文件中对应的 use/requires/import 语句，以此来找出内部依赖。**这固然是个非常贴心的小善举，**能够确保软件正常运行，但完全有可能造成比较奇怪的问题。比如我本次打包中rpm自作聪明地给我添加了一个libffmpeg.so的依赖，这东西整个Fedora自带的四个源里都不存在，在安装测试的时候出现了找不到依赖的情况。想我这种添加了找不到依赖的情况还算是运气好的，之前听说有人在使用opensuse的某个私人源的时候发现安装网易云音乐居然吧wps-office都给依赖上了，我想就是rpm自动检测到了网易云需要某个库，而wps恰好自带了这个库而导致的依赖误报。在Archlinux中，我们有一个叫namcap的小工具能够使用类似的方法检测软件运行时可能所需要的内部依赖，但他并不会默认启用，更不会自说自话的就直接把他添加为依赖，连一声也不吭。
其二是：rpm检测新增包内文件是否与系统已安装的软件包内的文件因为使用相同路径而冲突时，不仅会核对是否有冲突的同路径同名文件，他还会核对文件夹的文件占用情况。这说起来可能会有些抽象，我举个例子。在Fedora中，/usr/bin路径是被filesystem这个包所占有的，所以其他包在打包时是不能直接使用/usr/bin、/usr、甚至/来限定包内文件的范围的（也就是上面spec文件中的%files区域）。而我在第一次打包时，想要直接打包BUILDROOT下的所有文件，于是%files就直接填写了/作为限定，安装时提示/usr/bin和/usr/lib被filesystem这个包所占用，文件冲突。为此我还特意去仔细对比了Fedora自带的filesystem和我这个wechat-uos是否有冲突的文件，实则证明并没有，只是单纯这个检测机制过于死板罢了。而在Archlinux中，pacman安装时只会检测包内的文件是否与系统内的现有文件路径产生冲突，而不会非常无意义的去限定哪个文件夹是属于哪个包的。
附上本文的参考资料#
为了避免源网页失效，我特意去互联网档案馆做了备份
「在 Ubuntu 下直接将二进制文件制作成 rpm 包」 「Archive」
「解除RPM包的依赖的方法」 「Archive」
本文同时发布于「知乎专栏」，如果你恰好有知乎帐号的话或许可以考虑帮我点个赞？