Linux软件包打包实战:DEB与RPM从零构建指南
发布时间:2026/9/30 7:37:05来源:尧图网络
简介本资源是一份面向Linux系统管理员、运维工程师及开源软件打包初学者的RPM与DEB双体系软件包制作实战教程系统解决跨发行版如CentOS/RHEL与Ubuntu/Debian自定义软件打包、安装与维护的核心问题。文档以结构化方式详解两种包格式的目录规范、元数据文件control/spec编写要点、生命周期脚本preinst/postinst/prerm/postrm及%pre/%post等设计逻辑并覆盖从环境准备、文件组织、命令打包dpkg -b / rpmbuild -bb到安装、升级、卸载的全流程操作。资源为单个Word文档.doc大小267KB内容详实、示例丰富含aktd-client等真实打包案例的目录树、control字段说明、spec配置参数及Shell脚本片段便于对照实践与快速复用。目前已有416人学习下载适合希望掌握底层打包机制、提升自动化部署能力的中阶Linux从业者。1. RPM 和 DEB 软件包打包不是“配环境”而是 Linux 发行版兼容性落地的硬门槛一个 control 文件写错Ubuntu 用户装不上一个 %install 路径漏斜杠CentOS 服务器直接报错退出你有没有遇到过这样的场景开发完一个 Java 客户端比如文档里提到的aktd-client本地跑得好好的一发给运维说“打包成 deb 给 Ubuntu 用”结果对方回你一句“dpkg -i 报 dependency problemsbaidunetdisk 那种依赖冲突都算轻的我们这连 control 里的 Architecture 都不认”或者你辛辛苦苦写好 spec 文件rpmbuild -ba一跑BUILDROOT 下空空如也日志只甩一句error: File not found by glob: /root/rpmbuild/BUILDROOT/aktd-client-1.0-1.x86_64/usr/lib/aktd-client/*——连文件都没拷进去这不是玄学是打包流程里每个目录权限、每行换行符、每个路径斜杠都卡着你上线节奏的真实现场。这份《RPM 和 DEB 软件包打包教程.doc》不是理论手册它是一线工程师在 CentOS 7/8、Ubuntu 20.04/22.04、麒麟 V10 等真实环境中反复踩坑后拆解出的最小可行打包路径从DEBIAN/control的字段语义到SPECS/*.spec中%files的 glob 匹配边界从dpkg -b的目录所有权校验到rpmbuild --define _topdir的路径穿透陷阱。适合两类人一是刚接手遗留 Java 客户端交付的 DevOps 工程师需要 30 分钟内打出可验证 deb/rpm二是想把自研工具比如带 JDK 嵌入的桌面应用统一分发到多发行版的开发者——别再靠tar.gz README.md救火了真正的发行版兼容就藏在这两个包格式的结构契约里。2. DEB 打包从目录结构到 dpkg -b 的四步闭环control 文件字段必须和 dpkg --print-architecture 对齐DEB 打包表面看是dpkg -b一条命令实则是个精密装配流水线目录结构是模具control 是图纸四个 maintainer scriptpreinst/postinst/prerm/postrm是质检工位缺一不可。下面按实际构建顺序拆解每一步都带可复现命令和参数逻辑说明。2.1 目录结构DEBIAN 必须全大写且位于根目录usr/lib/aktd-client 的路径要和 postinst 中 chmod 一致DEB 包本质是归档文件但dpkg -b对目录结构有强约定。以aktd为例正确结构如下注意大小写和层级aktd/ # 打包主目录名称任意但建议与软件名一致 ├── DEBIAN/ # 必须全大写小写 debian 会被 dpkg 忽略 │ ├── control # 必须存在UTF-8 无 BOMUnix 换行LF │ ├── preinst # 可选但若存在必须可执行chmod x │ ├── postinst # 可选同上 │ ├── prerm # 可选 │ └── postrm # 可选 ├── usr/ # 与系统 /usr 对应非 /USR 或 /Usr │ └── lib/ │ └── aktd-client/ # 此路径将映射到目标机 /usr/lib/aktd-client/ │ ├── aktd-client.jar │ ├── start.sh │ ├── jdk.tar.gz │ ├── app.png │ └── aktd-client.desktop └── etc/ # 可选若需配置文件 └── aktd/ └── config.yaml提示DEBIAN目录权限必须为755内部脚本如postinst权限必须为755否则dpkg -b会静默失败或安装时报permission denied。执行chmod 755 DEBIAN/ chmod 755 DEBIAN/*.sh是安全起点。关键点在于usr/lib/aktd-client/这个路径不仅是文件存放位置更是postinst中chmod和cp命令的操作基准。例如文档中postinst有cp $sourcePath/$desktopName $desktopPath/$desktopName其中$sourcePath/usr/lib/aktd-client就严格依赖此目录结构。若你把程序放在usr/local/aktd/而postinst还写/usr/lib/...安装时必然失败。2.2 control 文件Architecture 字段必须用 dpkg --print-architecture 输出值Installed-Size 是估算值而非磁盘占用DEBIAN/control是 DEB 包的身份证字段缺失或格式错误会导致dpkg -i直接拒绝安装。以下是基于文档示例的精简可运行版本已去除冗余空行字段间用单空格分隔Package: aktd-client Version: 1.0.0 Architecture: amd64 Maintainer: opscompany.com Installed-Size: 120560 Depends: openjdk-11-jre | java-runtime, libgtk-3-0 Homepage: https://hab.com/aktd Description: AKTD client for secure remote management Section: utils Priority: optional参数逐条说明Package: 软件名必须小写字母数字短横线不能含下划线_dpkg会报错invalid package name。Version: 语义化版本1.0.0合法1.0.0-beta也合法但1.0.0.1可能被某些旧版 APT 解析异常建议用1.0.0~beta1格式。Architecture:这是最大坑点。必须与目标系统dpkg --print-architecture输出完全一致。Ubuntu 22.04 x86_64 输出amd64ARM64 服务器输出arm64不是x86_64或aarch64。填错则dpkg -i提示package architecture (amd64) does not match system (arm64)。Installed-Size: 单位是 KB是du -sk计算aktd/目录下所有文件不含 DEBIAN/的总和。dpkg -b不自动计算必须手动填。填小了APT 会警告但继续填大了不影响安装但用户看到“占用 200MB”实际只占 50MB 会质疑可信度。Depends: 依赖项用逗号分隔|表示“或”。openjdk-11-jre | java-runtime表示只要满足其一即可。注意java-runtime是虚拟包实际由openjdk-11-jre或default-jre提供避免硬绑具体包名。Section和Priority: 影响 APT 分类和升级策略utils和optional是最安全组合required仅用于核心系统组件。2.3 maintainer scriptspostinst 必须处理 /usr/share/applications 权限prerm 要 kill 进程而非仅 stop 服务DEB 的四个脚本不是可有可无的装饰它们是安装/卸载原子性的保障。文档中postinst示例包含图标复制和 JDK 解压但遗漏了关键权限修复#!/bin/sh set -e sourcePath/usr/lib/aktd-client desktopPath/usr/share/applications iconPath/usr/share/icons/aktd-client logsPath/usr/lib/aktd-client/logs # 创建目录并设权限必须否则 desktop 文件不生效 mkdir -p $desktopPath $iconPath $logsPath chmod 755 $desktopPath $iconPath $logsPath # 复制 desktop 文件并设权限644 是标准 cp $sourcePath/aktd-client.desktop $desktopPath/aktd-client.desktop chmod 644 $desktopPath/aktd-client.desktop # 复制图标 cp $sourcePath/app.png $iconPath/app.png chmod 644 $iconPath/app.png # 解压 JDK注意tar -xzvf 要指定 -C 目标目录 tar -xzvf $sourcePath/jdk.tar.gz -C $sourcePath/ # 启动服务如果 systemd 管理 if [ -f /etc/systemd/system/aktd-client.service ]; then systemctl daemon-reload systemctl enable aktd-client.service systemctl start aktd-client.service fi为什么必须加chmod 755Linux 桌面环境GNOME/KDE要求/usr/share/applications/目录及其子文件对other用户可读r--否则应用菜单不显示。dpkg默认创建目录权限为755但若目标机/usr/share/applications本身权限是750某些加固系统cp后文件权限继承父目录导致 desktop 文件不可读。显式chmod是唯一可靠方案。prerm脚本则要更激进文档示例只删文件但生产环境必须终止进程。安全写法#!/bin/sh set -e # 先尝试优雅停止 if systemctl is-active --quiet aktd-client.service; then systemctl stop aktd-client.service systemctl disable aktd-client.service fi # 强制 kill 剩余进程防止 java -jar 残留 pkill -f aktd-client.jar || true pkill -f start.sh || true|| true防止pkill无匹配时脚本退出确保后续清理继续。2.4 dpkg -b 打包命令后必须跟目录名输出 deb 名称中的架构要和 control 一致打包命令看似简单但参数顺序和命名规则极易出错# 正确dpkg -b 源目录 输出deb文件名 dpkg -b aktd aktd-client_1.0.0_amd64.deb # 错误1漏掉输出文件名dpkg 会生成 aktd.deb但 control 中 Architecture 是 amd64矛盾 dpkg -b aktd # ❌ 生成 aktd.deb安装时报 architecture mismatch # 错误2输出名中架构与 control 不一致 dpkg -b aktd aktd-client_1.0.0_arm64.deb # ❌ control 写的是 amd64安装失败 # 错误3源目录名含空格或特殊字符dpkg 不支持 dpkg -b aktd client aktd-client.deb # ❌ 报错dpkg-deb: error: failed to open package archive验证 deb 是否有效打包后立即用dpkg -I aktd-client_1.0.0_amd64.deb查看元数据确认Architecture、Version与control一致用dpkg -c aktd-client_1.0.0_amd64.deb | head -20检查文件列表是否包含usr/lib/aktd-client/下所有文件。这两步花 10 秒省去后续 1 小时排查。3. RPM 打包rpmbuild 的 _topdir 是根目录SPEC 文件中 %install 必须用 %{buildroot} 而非绝对路径RPM 打包比 DEB 更重它强制要求标准化工作流SOURCES/SPECS/RPMS 等目录rpmbuild不是简单归档而是模拟安装过程的编译-安装-打包三阶段。核心在于理解BUILDROOT是沙箱%{buildroot}是你在 spec 中唯一能写的“根路径”。3.1 目录结构_topdir 必须是绝对路径SPECS 下 spec 文件名要和 %name-%version 匹配RPM 要求固定顶层目录_topdir其子目录结构是硬编码的。以/opt/rh/rpm为例/opt/rh/rpm/ ├── BUILD/ # 编译源码时的临时目录rpmbuild 自动创建 ├── BUILDROOT/ # “虚拟根目录”所有 install 操作在此发生 ├── RPMS/ # 最终 rpm 存放处按架构分目录x86_64/ ├── SOURCES/ # 放源码压缩包如 aktd-client-1.0.0.tar.gz │ └── aktd-client-1.0.0.tar.gz ├── SPECS/ # 放 spec 文件 │ └── aktd-client.spec # 文件名建议与 %name 一致 └── SRPMS/ # 源码 rpm 存放处关键约束_topdir必须是绝对路径/opt/rh/rpm合法./rpm非法且当前用户对该路径有读写权限。SPECS/aktd-client.spec中%name必须为aktd-client否则rpmbuild会报error: Name field must be present。SOURCES/下的源码包名必须与 spec 中%setup -n或%autosetup参数匹配。例如%setup -n aktd-client-1.0.0要求SOURCES/下有aktd-client-1.0.0.tar.gz。注意rpmbuild默认_topdir是~/rpmbuild但文档示例用--define _topdir /opt/rh/rpm这意味着你必须先mkdir -p /opt/rh/rpm/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}并chown $USER:$USER /opt/rh/rpm否则rpmbuild会因权限不足失败。3.2 SPEC 文件%install 阶段必须用 %{buildroot}%files 中路径必须以 / 开头SPEC 文件是 RPM 的灵魂它定义了从源码到二进制包的全部逻辑。以下是一个精简、可运行的aktd-client.spec基于文档但修正了路径和语法Name: aktd-client Version: 1.0.0 Release: 1%{?dist} Summary: AKTD client for secure remote management License: GPL Group: Applications/System URL: https://hab.com/aktd Source0: aktd-client-%{version}.tar.gz %description AKTD client provides secure remote management interface. %prep %setup -n aktd-client-%{version} %build # Java 项目通常无需编译此阶段可空或做验证 echo No build needed for jar package %install rm -rf %{buildroot} mkdir -p %{buildroot}/usr/lib/aktd-client mkdir -p %{buildroot}/usr/share/applications mkdir -p %{buildroot}/usr/share/icons/aktd-client mkdir -p %{buildroot}/usr/lib/systemd/system # 复制文件到 buildroot关键必须用 %{buildroot} cp -p aktd-client.jar %{buildroot}/usr/lib/aktd-client/ cp -p start.sh %{buildroot}/usr/lib/aktd-client/ cp -p jdk.tar.gz %{buildroot}/usr/lib/aktd-client/ cp -p app.png %{buildroot}/usr/share/icons/aktd-client/ cp -p aktd-client.desktop %{buildroot}/usr/share/applications/ cp -p aktd-client.service %{buildroot}/usr/lib/systemd/system/ %files %defattr(-,root,root,-) /usr/lib/aktd-client/ /usr/share/applications/aktd-client.desktop /usr/share/icons/aktd-client/app.png /usr/lib/systemd/system/aktd-client.service %post # 设置权限和启动服务 chmod 755 /usr/lib/aktd-client/start.sh chmod 644 /usr/share/applications/aktd-client.desktop chmod 644 /usr/share/icons/aktd-client/app.png systemctl daemon-reload systemctl enable aktd-client.service systemctl start aktd-client.service %preun if systemctl is-active --quiet aktd-client.service; then systemctl stop aktd-client.service fi %postun if [ $1 -eq 0 ]; then systemctl disable aktd-client.service rm -f /usr/share/applications/aktd-client.desktop rm -f /usr/share/icons/aktd-client/app.png fi %clean rm -rf %{buildroot}核心参数解析%install阶段所有cp命令目标路径必须以%{buildroot}开头%{buildroot}在构建时被替换为/opt/rh/rpm/BUILDROOT/aktd-client-1.0.0-1.x86_64。写成/usr/lib/...会直接写入宿主机根目录导致权限错误甚至系统损坏。%files列表路径必须以/开头且是buildroot中的相对路径即去掉%{buildroot}后的部分。/usr/lib/aktd-client/表示该目录下所有文件递归都包含在 rpm 中/usr/lib/aktd-client/aktd-client.jar则只包含该文件。%post和%preun%post在安装完成后执行%preun在卸载前执行$1是 rpm 的erase操作数0表示完全卸载。Release: 1%{?dist}%{?dist}自动扩展为.el8CentOS 8、.fc38Fedora 38等确保跨发行版兼容。3.3 rpmbuild 命令-ba 表示 build all--define 必须在 spec 路径前打包命令rpmbuild -ba /opt/rh/rpm/SPECS/aktd-client.spec --define _topdir /opt/rh/rpm中参数顺序至关重要# 正确--define 必须在 spec 文件路径之后 rpmbuild -ba /opt/rh/rpm/SPECS/aktd-client.spec --define _topdir /opt/rh/rpm # 错误1--define 在 -ba 前rpmbuild 会忽略 rpmbuild --define _topdir /opt/rh/rpm -ba /opt/rh/rpm/SPECS/aktd-client.spec # ❌ 使用默认 ~/rpmbuild # 错误2spec 路径写错rpmbuild 找不到文件 rpmbuild -ba SPECS/aktd-client.spec --define _topdir /opt/rh/rpm # ❌ 相对路径报错 no such file # 错误3用 -bb只 build binary但 spec 中有 %prep/%build会失败 rpmbuild -bb /opt/rh/rpm/SPECS/aktd-client.spec --define _topdir /opt/rh/rpm # ❌ 缺少 %install 阶段成功标志命令执行后/opt/rh/rpm/RPMS/x86_64/aktd-client-1.0.0-1.el8.x86_64.rpm或类似生成且rpm -qpi aktd-client-1.0.0-1.el8.x86_64.rpm显示Architecture: x86_64、Version: 1.0.0与 spec 一致。3.4 避坑 / 常见问题 / 排查rpmbuild 的五个血泪经验从 BUILDROOT 权限到 desktop 文件不生效RPM 打包的坑比 DEB 更隐蔽因为错误常发生在构建中间态而非最终安装。以下是我在 CentOS 7/8、Fedora 36/38 上踩过的典型问题现象 1rpmbuild 报错error: File not found by glob: /root/rpmbuild/BUILDROOT/.../usr/lib/aktd-client/*→原因%install阶段cp命令未成功执行或BUILDROOT目录权限不足rpmbuild以当前用户运行若_topdir属于 root则BUILDROOT不可写。→解决检查ls -ld /opt/rh/rpm/BUILDROOT确保属主是当前用户在%install开头加echo Copying files...和ls -la调试用strace -e tracemkdir,open,write rpmbuild ...抓系统调用。现象 2rpm -ivh 安装后/usr/lib/aktd-client/下文件权限全是 600只读→原因%files中未声明%defattrrpm 默认用umask 077创建文件。→解决在%files段首加%defattr(-,root,root,-)其中-表示使用源文件权限root,root是属主属组-是 umask空表示不限制。现象 3安装后桌面菜单无图标/usr/share/applications/aktd-client.desktop存在但 GNOME 不识别→原因desktop 文件缺少[Desktop Entry]头或Exec路径错误如写成Exec/usr/lib/aktd-client/start.sh但实际start.sh无执行权限或Icon路径指向/usr/lib/aktd-client/app.png应为/usr/share/icons/aktd-client/app.png。→解决用desktop-file-validate /usr/share/applications/aktd-client.desktop检查语法chmod x /usr/lib/aktd-client/start.shupdate-desktop-database刷新缓存。现象 4rpmbuild -ba报错error: Bad exit status from /var/tmp/rpm-tmp.xxx (%install)→原因%install阶段 shell 命令返回非零状态如cp源文件不存在、mkdir -p权限不足。→解决在%install开头加set -e已默认开启并在关键命令后加echo $?检查SOURCES/下源码包是否完整tar -tzf aktd-client-1.0.0.tar.gz | head。现象 5安装 rpm 后systemctl start aktd-client.service报Failed to start aktd-client.service: Unit not found→原因%files未包含aktd-client.service文件或cp命令路径写错如cp aktd-client.service %{buildroot}/usr/lib/systemd/system/但源文件在SOURCES/而非BUILD/。→解决确认SOURCES/下有aktd-client.service在%install中用cp -v显示复制详情rpm -qlp aktd-client-1.0.0-1.el8.x86_64.rpm | grep service验证文件是否在包内。4. DEB 与 RPM 安装/升级/卸载实战dpkg 和 rpm 命令的隐含行为差异以及依赖冲突的绕过策略打包只是第一步安装、升级、卸载才是用户真实接触的环节。dpkg和rpm命令表面相似但底层逻辑差异巨大dpkg是底层包管理器不解决依赖rpm同样不自动装依赖但dnf/yum会调用它并补全。理解这些差异才能写出用户友好的包。4.1 dpkg 安装-i 会触发 maintainer scripts-r 不卸载配置文件-P 才彻底清除dpkg -i不是简单解压它会按顺序执行preinst→ 解包 →postinst。若postinst失败整个安装回滚dpkg自动删除已解包文件。例如# 安装sudo 必须因写入 /usr/lib sudo dpkg -i aktd-client_1.0.0_amd64.deb # 升级同名包自动覆盖触发 prerm → preinst → 解包 → postinst sudo dpkg -i aktd-client_1.0.1_amd64.deb # 卸载保留配置文件如 /etc/aktd/config.yaml sudo dpkg -r aktd-client # 彻底卸载删除配置文件相当于重装 sudo dpkg -P aktd-client关键区别dpkg -r只移除程序文件/etc/下配置保留下次安装可复用。dpkg -Ppurge会执行postrm脚本并删除/etc/配置适合彻底清理。dpkg -i若遇依赖缺失如Depends: openjdk-11-jre未安装会报dependency problems prevent configuration of aktd-client并停在“未配置”状态此时sudo apt --fix-broken install可自动补依赖。4.2 rpm 安装-ivh 的 v 是 verboseh 是 hash 进度--replacefiles 解决文件冲突rpm -ivh是最常用安装命令各参数含义# -i: install, -v: verbose显示详细信息, -h: hash显示 ####### 进度条 sudo rpm -ivh aktd-client-1.0.0-1.el8.x86_64.rpm # 升级-U 替换旧包-v 显示详情-h 显示进度 sudo rpm -Uvh aktd-client-1.0.1-1.el8.x86_64.rpm # 卸载-e: erase包名是 aktd-client不是文件名 aktd-client-1.0.0-1.el8.x86_64.rpm sudo rpm -e aktd-client # 强制安装覆盖已存在文件解决 file /usr/lib/aktd-client/start.sh from install of aktd-client-1.0.0-1.el8.x86_64 conflicts with file from package xxx sudo rpm -ivh --replacefiles aktd-client-1.0.0-1.el8.x86_64.rpm为什么需要--replacefiles当系统已存在同名文件如其他包也装了/usr/lib/aktd-client/start.shrpm默认拒绝安装以防覆盖。--replacefiles强制覆盖适用于测试环境或明确知道文件来源的场景。生产环境应避免改用--force更激进忽略所有冲突风险更高。4.3 依赖冲突实战dpkg: dependency problems prevent configuration of baidunetdisk 这类报错的三种解法网络热搜中dpkg: dependency problems prevent configuration of baidunetdisk是经典依赖地狱。根本原因是dpkg只校验control中Depends字段不自动解决。解决方案分三层解法 1用 apt 自动补依赖推荐# 安装 deb 后若报 dependency problems立即运行 sudo apt --fix-broken install # apt 会分析缺失包如 openjdk-11-jre下载并安装然后重新配置 aktd-client解法 2手动安装依赖调试用# 从报错中提取缺失包名如 baidunetdisk depends on libqt5core5a sudo apt install libqt5core5a # 再配置未完成的包 sudo dpkg --configure -a解法 3降级或跳过依赖检查仅限紧急# 强制安装忽略 Depends风险高可能运行失败 sudo dpkg -i --ignore-dependsopenjdk-11-jre aktd-client_1.0.0_amd64.deb # 或用 apt 下载依赖包不安装 apt download openjdk-11-jre # 手动 dpkg -i 安装依赖包 sudo dpkg -i openjdk-11-jre_*.deb注意--ignore-depends是最后手段。aktd-client依赖 JDK若强行忽略start.sh执行时会报java: command not found用户无法启动。4.4 验证安装结果从文件存在性到 desktop 文件注册的四层检查安装后不能只信“成功”提示必须逐层验证检查层级命令预期输出说明1. 文件存在dpkg -L aktd-client | head -5或rpm -ql aktd-client | head -5/usr/lib/aktd-client/,/usr/share/applications/aktd-client.desktop确认包内文件已解压到正确路径2. 权限正确ls -l /usr/lib/aktd-client/start.sh-rwxr-xr-x 1 root root ...start.sh必须可执行否则桌面菜单点击无响应3. desktop 注册desktop-file-validate /usr/share/applications/aktd-client.desktop无输出静默成功语法检查缺失TypeApplication或Exec会报错4. 应用可见grep -A5 aktd-client /usr/share/applications/aktd-client.desktopNameAKTD ClientExec/usr/lib/aktd-client/start.sh确认 Name 和 Exec 字段正确GNOME/KDE 依赖此终极验证在 GUI 环境中打开“应用程序菜单”搜索 “AKTD”点击图标应启动start.sh。若失败journalctl -u aktd-client.service -n 20查 systemd 日志或sudo -u $USER /usr/lib/aktd-client/start.sh手动执行看报错。5. 打包自动化与跨发行版适配用 shell 脚本统一生成 deb/rpm以及麒麟 V10 的特殊处理技巧手工打包适合学习但交付时必须自动化。我用一个 50 行 shell 脚本实现了./build.sh 1.0.0一键生成aktd-client_1.0.0_amd64.deb和aktd-client-1.0.0-1.el8.x86_64.rpm。更重要的是面对国产化环境如麒麟 V10需针对性调整——它基于 Ubuntu 20.04但dpkg --print-architecture输出amd64apt源却用k10代号desktop文件注册机制略有不同。5.1 自动化打包脚本用变量驱动 dpkg 和 rpmbuild避免重复劳动以下build.sh是真实生产环境使用的简化版去除了日志和错误处理聚焦逻辑#!/bin/bash # build.sh VERSION VERSION${1:-1.0.0} ARCHamd64 DISTel8 # 清理旧包 rm -f aktd-client_${VERSION}_${ARCH}.deb rm -f /opt/rh/rpm/RPMS/x86_64/aktd-client-${VERSION}-1.${DIST}.x86_64.rpm # 构建 DEB echo Building DEB... mkdir -p aktd/DEBIAN aktd/usr/lib/aktd-client aktd/usr/share/applications aktd/usr/share/icons/aktd-client cp -r src/* aktd/usr/lib/aktd-client/ cp src/aktd-client.desktop aktd/usr/share/applications/ cp src/app.png aktd/usr/share/icons/aktd-client/ chmod 755 aktd/DEBIAN/ aktd/usr/lib/aktd-client/start.sh chmod 644 aktd/usr/share/applications/aktd-client.desktop aktd/usr/share/icons/aktd-client/app.png # 生成 control动态填充 Version 和 Architecture cat aktd/DEBIAN/control EOF Package: aktd-client Version: ${VERSION} Architecture: ${ARCH} Maintainer: opscompany.com Installed-Size: $(du -sk aktd \| awk {print \$1}) Depends: openjdk-11-jre | java-runtime Description: AKTD client for secure remote management Section: utils Priority: optional EOF dpkg -b aktd aktd-client_${VERSION}_${ARCH}.deb # 构建 RPM echo Building RPM... mkdir -p /opt/rh/rpm/{SOURCES,SPECS,RPMS,BUILD,BUILDROOT,SRPMS} p a hrefhttps://download.csdn.net/download/qq_43681990/88510596 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
网站建设高端定制企业官网