首先你需要的是一个正确配置的构建树。这可以通过 /etc/rpmrc 文件进行配置。大多数人会直接使用 /usr/src。
你可能需要创建以下目录来构建构建树
BUILD 是 RPM 执行所有构建的目录。你不必在任何特定位置进行测试构建，但这是 RPM 将执行构建的位置。
SOURCES 是你应该放置原始源代码 tar 文件和补丁的目录。这是 RPM 默认查找的位置。
SPECS 是所有 spec 文件应该放置的目录。
RPMS 是 RPM 在构建完成后放置所有二进制 RPM 的位置。
SRPMS 是所有源代码 RPM 将被放置的位置。
你可能首先想要做的是让源代码在不使用 RPM 的情况下干净地构建。为此，解压源代码，并将目录名更改为 $NAME.orig。然后再次解压源代码。使用这个源代码进行构建。进入源代码目录并按照说明进行构建。如果你必须编辑内容，你需要一个补丁。一旦你成功构建，清理源代码目录。确保删除由 configure 脚本生成的所有文件。然后 cd 返回到源代码目录的父目录。然后你将执行类似的操作
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
这将为你创建一个补丁，你可以在你的 spec 文件中使用它。请注意，你在补丁名称中看到的 "linux" 只是一个标识符。你可能想要使用更具描述性的名称，例如 "config" 或 "bugs" 来描述你为什么必须制作补丁。在使用你创建的补丁文件之前查看它，以确保没有意外包含二进制文件，这也是一个好主意。
现在你有了可以构建的源代码，并且你知道如何构建它，构建并安装它。查看安装序列的输出，并从中构建你的文件列表，以便在 spec 文件中使用。我们通常与所有这些步骤并行构建 spec 文件。你可以创建初始文件并填写简单的部分，然后在进行其他步骤时填写其他部分。
一旦你有了 spec 文件，你就可以尝试构建你的软件包了。最有效的方法是使用如下命令
rpm -ba foobar-1.0.spec
还有其他选项可以与-b开关一起使用
p表示只运行 specfile 的 prep 部分。
l是一个列表检查，它对 %files 进行一些检查。
c执行 prep 和 compile。 当你不确定你的源代码是否可以构建时，这很有用。 这看起来似乎没用，因为你可能只想继续摆弄源代码本身直到它构建成功，然后再开始使用 RPM，但是一旦你习惯使用 RPM，你就会发现你会使用它的情况。
i执行 prep、compile 和 install。
b执行 prep、compile、install，并仅构建二进制软件包。
a构建所有内容（包括源代码和二进制软件包）。
有几个修饰符可以用于-b开关。 它们如下所示
--short-circuit将直接跳到指定的阶段（只能与 c 和 i 一起使用）。
--clean完成后删除构建树。
--keep-temps将保留在 /tmp 中创建的所有临时文件和脚本。 你实际上可以使用以下-v选项查看在 /tmp 中创建了哪些文件。
--test不执行任何实际阶段，但会保留临时文件。
一旦你为你的软件包有了源代码和二进制 rpm，你需要对其进行测试。 最简单也是最好的方法是使用与你正在构建的机器完全不同的机器进行测试。 毕竟，你刚刚在自己的机器上做了很多 make install，所以它应该安装得相当好了。
你可以在软件包上执行 rpm -e packagename 来进行测试，但这可能会具有欺骗性，因为在构建软件包时，你执行了 make install。 如果你遗漏了文件列表中的某些内容，则它不会被卸载。 然后你将重新安装二进制软件包，你的系统将再次完整，但你的 rpm 仍然不完整。 请确保记住，仅仅因为你执行了 rpm -ba package，大多数安装你的软件包的人都只会执行 rpm -i package。 确保你不在 build 或 install 部分执行任何需要在单独安装二进制文件时执行的操作。
一旦你制作了自己的 RPM 软件包（假设它是尚未被 RPM 化的东西），你可以将你的工作贡献给其他人（也假设你 RPM 化的东西是可自由分发的）。 为此，你需要将其上传到 ftp.redhat.com。
请参阅上面关于测试和如何处理新 RPM 的章节。 我们希望获得所有可用的 RPM，并且我们希望它们是好的 RPM。 请花时间好好测试它们，然后花时间上传它们以造福所有人。 另外，请确保你只上传可自由使用的软件。 商业软件和共享软件不应上传，除非它们具有明确声明允许这样做的版权。 这包括 ssh、pgp 等。