直接说结论：C# 不能原生操作 RPM/DEB 包
没有官方或主流 .NET 库能可靠地解包、构建或签名 RPM（
.rpm）或 DEB（
.deb）文件。这两个格式是 Linux 发行版专用的二进制包格式，深度绑定各自生态工具链（
rpmbuild、
dpkg-deb），不是通用归档格式。
为什么不能像 ZIP 那样用 System.IO.Compression
处理
RPM 和 DEB 看似“压缩包”，但内部结构复杂且带元数据校验：
RPM 是 CPIO 归档 + 前置二进制头 + GPG/SHA256 校验块，tar或
gzip工具无法直接解出有效内容 DEB 是 ar 归档（不是 tar），内含
debian-binary、
control.tar.gz、
data.tar.xz三部分，且
data.tar.xz的路径和权限必须严格符合 dpkg 规范，否则安装失败
System.IO.Compression不支持 ar 或 rpm 头解析；强行读取 raw bytes 容易破坏校验或忽略控制字段
可行方案：调用系统命令而非纯 C# 解析
在 Linux 环境下运行 C# 程序时，最稳的方式是委托给发行版原生工具，而不是自己实现解析逻辑：
解包 RPM：rpm2cpio package.rpm | cpio -idmv（需
rpm2cpio和
cpio） 解包 DEB：
dpkg-deb --raw-extract package.deb ./output或
ar x package.deb后再解压各 tar 成员 创建 DEB：必须生成合规的
control文件，用
dpkg-deb --build打包；RPM 则必须写
.spec并用
rpmbuild注意：C# 中用
Process.Start调用时，要设
UseShellExecute = false，捕获
StandardError——很多错误（如 control 缺字段、路径含空格）只报在 stderr 里
常见翻车点：路径、权限、编码
即使命令跑通，生成的包也常在目标机器上安装失败，问题多出在细节：
RPM 中文件路径必须以/开头，且不能有 Windows 风格反斜杠；C# 字符串拼接时容易漏掉或错写 DEB 的
control文件必须是 Unix 换行（
\n），且末尾要空一行；用
File.WriteAllText默认用 Windows 换行，在 Debian/Ubuntu 上会报
invalid format所有文件权限需显式设置（如
0755），C# 的
File.SetAttributes对 Linux 权限无效，得靠
chmod或打包工具自身规则 中文包名或描述需声明
UTF-8编码，否则
dpkg解析 control 时可能截断
真正难的从来不是“怎么调命令”，而是让输出包通过
rpm -K或
lintian检查——这些工具对元数据格式极其敏感，一个空格、一个换行、一个未转义的括号都会导致失败。
