Fedora的软件包使用RPM格式，但进入官方仓库的流程远不止执行一次rpmbuild：它要求源码整理、SPEC文件编写、干净环境验证、Bugzilla审查以及后续更新维护。理解完整路径后，打包者可以减少大量返工，也能更清楚地定位构建失败或审核退回的原因。
一、准备打包环境与目录结构
在Fedora上打包首先要准备专用工具和目录。普通用户即可完成大部分工作，不建议直接用root构建，因为脚本错误可能污染系统。安装fedora-packager会带入rpmdevtools、rpmlint、mock等工具，执行以下命令即可完成初始配置：
sudo dnf install fedora-packager rpmdev-setuptree
rpmdev-setuptree会在家目录创建rpmbuild目录，包括BUILD、RPMS、SOURCES、SPECS、SRPMS五个子目录。BUILD保存编译过程文件，RPMS保存生成的二进制RPM，SOURCES保存源码包和补丁，SPECS保存描述打包规则的spec文件，SRPMS保存源码RPM。把官方源码tarball放到SOURCES目录，补丁文件也放这里。为了让mock构建不需要频繁输入密码，把当前用户加入mock组：
sudo usermod -aG mock $USER newgrp mock
mock会在隔离环境中安装BuildRequires并重新构建包，这样可以验证spec文件里声明的依赖是否完整。宿主机上可能已经安装了很多开发库，导致构建成功但遗漏依赖，mock能从源头避免这类问题。
开始编写spec前，建议先浏览Fedora Packaging Guidelines，重点关注命名规则、License字段、架构支持、systemd服务打包等部分。Fedora对许可证标识要求较严格，优先使用SPDX短标识，例如MIT、GPL-2.0-or-later。多个许可证同时存在时需要写组合表达式，不要只写一个模糊的Custom。
二、编写SPEC文件与本地验证
spec文件是RPM打包的核心，它告诉rpmbuild如何准备源码、应用补丁、编译、安装到虚拟根目录，以及最终归档哪些文件。可以先用rpmdev-newspec生成一个模板再手写调整：
rpmdev-newspec mypackage.spec
下面是一个最小可用的spec示例，适合使用autotools或make构建的C语言项目：
Name: mypackage
Version: 1.0.0
Release: 1%{?dist}
Summary: A small demo package
License: MIT
URL: https://ipipp.com/mypackage
Source0: %{name}-%{version}.tar.gz
BuildRequires: gcc
BuildRequires: make
%description
A small demo package for Fedora packaging guide.
%prep
%autosetup
%build
%configure
%make_build
%install
%make_install
%files
%license LICENSE
%doc README.md
%{_bindir}/mypackage
%changelog
* Fri Feb 14 2025 Your Name <you@ipipp.com> - 1.0.0-1
- Initial package
%prep阶段的%autosetup会自动解压源码并应用所有Patch。%build阶段使用%configure和%make_build宏，这些宏会自动带上Fedora的编译器参数和并行编译选项。%install阶段不要直接写make install，而应使用%make_install宏，让安装路径正确落入构建根目录。%files列出需要进入RPM的文件，%license和%doc宏会把文件放到对应目录。未列出的文件会导致构建失败，列出却不存在的文件同样会报错。
本地构建时进入SPECS目录执行rpmbuild：
cd ~/rpmbuild/SPECS rpmbuild -ba mypackage.spec
-ba选项会同时生成二进制RPM和SRPM。构建结束后用rpmlint检查：
rpmlint ~/rpmbuild/SRPMS/mypackage-1.0.0-1.fc*.src.rpm rpmlint ~/rpmbuild/RPMS/x86_64/mypackage-1.0.0-1.fc*.x86_64.rpm
常见警告包括Summary以句号结尾、文件权限异常、源码包含预编译二进制、缺少%changelog等。Fedora审核对rpmlint输出比较敏感，尽量清零或给出合理解释。之后再用mock做干净环境构建：
mock -r fedora-rawhide-x86_64 --rebuild ~/rpmbuild/SRPMS/mypackage-1.0.0-1.fc*.src.rpm
mock会从官方仓库拉取BuildRequires，在隔离的干净目录里重新构建。如果这一步失败，通常说明spec里少了某个依赖，或者源码在干净环境下无法编译。解决本地mock问题后再进入下一步，可以大幅降低后续审核成本。
三、使用Copr进行公开测试
Copr是Fedora社区的第三方构建服务，可以在线构建SRPM并生成个人仓库。它的构建环境接近官方构建系统，适合在提交官方仓库前做公开测试。先安装copr-cli并配置API令牌，然后创建项目并上传SRPM：
sudo dnf install copr-cli copr-cli create my-test-repo --chroot fedora-rawhide-x86_64 copr-cli build my-test-repo ~/rpmbuild/SRPMS/mypackage-1.0.0-1.fc*.src.rpm
构建完成后Copr会生成一个仓库地址。其他用户可以启用该仓库并安装测试：
sudo dnf copr enable yourusername/my-test-repo sudo dnf install mypackage
Copr还可以关联Git仓库，自动根据spec和源码进行构建，适合持续集成场景。构建日志和rpmlint输出能帮助发现本地mock未暴露的问题，例如架构相关错误或网络访问限制。虽然Copr不能替代官方仓库审核，但它是提交前降低风险的重要手段。把自己维护的软件先放到Copr测试几周，收集用户反馈，会让后续Bugzilla审查更顺利。
四、提交官方仓库：Bugzilla审查与dist-git
官方仓库提交需要FAS账号并签署Fedora Project Contributor Agreement。新打包者通常需要现有维护者赞助，可以通过参与现有包维护或提交高质量审核来积累信誉。为自己新包开启审核时，在Bugzilla中新建Review Request，组件选择Package Review，并提供SPEC和SRPM的URL。通常使用fedora-review工具生成基础报告：
sudo dnf install fedora-review fedora-review -b BUGZILLA_ID
fedora-review会下载包并在mock中构建，输出review.txt。审核者会重点关注许可证、文件归属、宏使用、补丁来源等内容。通过审核后，请求创建dist-git仓库。src.fedoraproject.org是Fedora包源码托管平台，采用git管理，每个RPM包对应一个仓库。用fedpkg操作：
fedpkg clone rpms/mypackage cd mypackage fedpkg import ~/rpmbuild/SRPMS/mypackage-1.0.0-1.fc*.src.rpm git commit -m "Initial import" git push fedpkg build
fedpkg build会触发Koji构建官方二进制包。构建成功后，稳定版更新还要通过Bodhi创建更新，填写类型、严重等级和测试说明。稳定版通常需要足够的测试反馈或等待时间阈值才能进入stable仓库。如果只是Rawhide包，可以不走Bodhi，直接构建即可。每次版本升级都要修改Version、Release，追加changelog，并注意保持向后兼容。
五、常见问题与提交建议
架构支持是一个容易被忽略的点。如果软件只支持x86_64，需要在spec中通过ExcludeArch明确排除其他架构，并说明原因；如果支持多架构，最好在aarch64等环境中也验证一次。Copr和mock都可以选择不同架构的chroot，提前测试能避免仓库构建失败。
许可证识别同样容易出问题。不要凭印象填写License字段，应当检查源码中的许可证声明和所有第三方组件。Fedora要求使用SPDX标识，多个许可证用AND或OR连接。如果上游没有明确声明，应先联系上游确认，而不是直接选择Custom绕过审核。
补丁管理方面，尽量不要在%prep中直接使用sed修改源码。把修改做成Patch文件，并在spec中声明Patch0，再在%changelog中说明补丁来源。这样可以追踪变更，也方便上游版本升级后判断补丁是否仍然需要。
最后，与上游保持合作能显著减少维护成本。优先把Fedora需要的构建修复提交给上游，而不是长期在下游维护大段补丁。提交官方仓库不只是完成一次打包，而是承担起后续更新、安全修复和社区反馈的责任。走通环境准备、SPEC编写、Copr测试、Bugzilla审查和dist-git维护这条链路，软件才能真正融入Fedora生态。
Fedora软件打包RPM打包Copr仓库修改时间：2026-09-24 10:44:30