RPM建包原理.pdf

RPM 建包原理 为什么要打包？ 制作 rpm 不仅仅是打包，更可以解决菜单创建、打补钉、完成大量预配置、与其他软件 包互动等操作。使用源代码安装要求用户了解基本的编译过程、能够应付各种不能编译 的意外、必须自己完成抽象的配置、甚至懂得软件开发，能够自己打补钉，……对非计算 机专业的用户而言简直就是天方夜谭。这是把软件开发的最后一步抛给了用 户，作为发 行版，这是极不负责任的！也是不现实的，除非用 lfs ，但那是一本菜谱，不是真正的发 行版。 软件作者发布源代码是正确的，负责的作者一般都同时提供 rpm 和 deb 包以及它们的源 代码包。除非他们不会制作。愿意使用什么，那是个人的自由，但对外就不能只想到自己 。 GNU 精神是一种公益精神，没有奉献精神，在自由软件领域是要遭唾弃的！ 直 接使用其他发行版的 rpm 常常是不行的。不知道大家看没看“恼人的依赖关系”这个 帖子。可以在技术支持区有哪些信誉好的足球投注网站一下。任何两个发行版本在二进制上都是不能兼容的！他们 实际是不同的操 作系统。不仅使用的库文件不同，配置也迥异。特别是同一个发行版的 不同版本更不兼容。任何包都必须在本地重新编译，而且不一定通得过，因为还有 spec 宏的兼容问题！如果要在别的发行版上使用，必须用源码编译，这是常识。考虑文件布局 和配置问题，有时直接编译也是不够的，必须修改 spec ，甚至自己打补丁。 如何创建 rpm 包？ rpm 建包原理其实不复杂。写 spec 相当于一种脚本编程，主要是在 spec 里提供一些软件 相关信息，以及安装、卸载前后要执行的脚本，然后展开压缩的源代码包，打上补丁，执 行编译，然后利用 make install 可以重新指定安装目的地的特性，把编译好的文件安装到 指定的虚拟根目录下的指定位置里，一般是虚拟的 /usr 里，然后把这些目录、信息和脚本 打成一个压缩包，即 rpm 包。同时可选地生成源码包 src.rpm 。当然有很多具体细节问题。 您应该首先阅读软件的 readme 和 INSTALL 文件。 打包原则 1. 任何人都应该在系统现有 src.rpm 的 spec 基础上修改更新，除非没有这样的包。这可以 省去很多麻烦，少走弯路。 2. 任何人都无权删除别人的 changelog 和原始打包者的信息，这是对别人的不尊重。但你 可以追加自己的信息。 3. 尽可能在 spec 里使用系统的标准宏定义，而不要用非标准写法。 4. 任何人都不应该直接提供修改后的源代码，而应该以补丁形 发布你的修改，在 spec 里完成打补丁操作。务必做到一个补丁只解决一个问题，这样才能确保补丁的可重用性， 否则版本升级后补丁很容易失效。如果你确信自己的补丁是清洁补丁，尽可 能发给上游 开发者，这样才能一劳永逸。你所打的任何补丁，其授权方 必须和被修改源代码保持一 致。 5. rpm 不是跨平台打包技术。确保软件的二进制代码能够跨平台运行，不是系统软件打包 者要考虑的事，而是应用软件作者和独立二进制代码发布者应该考虑的事。我们没 有责 任和义务确保从我们系统里拆解下来的部件能够运行于其他系统上，不支持，更不提倡这 种移花接木的作法。 试图解决跨平台问题的打包技术，我印象中有 autopackage 和 klik 技术，参见： http://klik.atekon.de 预备知识 ： 首先我们观察一下 rpm 文件名的特点。一个 rpm 包文件名通常由 5 段组成： %{name}-%{version}-%{release}.ix86.rpm cutedict-1.1-1mgc.i686.rpm 这里 %{name}=cutedict ，%{version}=1.1 ，%{release}=1mgc ，ix86=i686 ，如果是为 athlon 芯片家族编译的包，这里就是 athlon ，依此类推。 注意： 下面是一个 spec 模板。 1. 凡是行首加上 # 的都被注释掉了，实际运行时不起作用，如要使其生效，请去掉注释符 # 。 2. 凡是以 %{***} 和 %*** 形式出现的符号都是“宏”，很多宏都是系统预定义的 ［注 2］，也可以是自己定义的。 3. 下面的黑体字是 spec 文件的关键字，不能写错。 4. 有不明白的地方可以参见跟帖里的参考文献。 5. 如果软件没有使用 GNU autot l 创建，而是自己写的 Makefile ，这就导致不能按照常 规方法打包，非常麻烦。 6. 服务器软件通常都需要大量预配置工作，spec 打包绝非一两天