Catalog
Showing posts 1 - 3 of 3.
View more »
|
RPM Building
RPM 套件打包入门
一、准备工作 1.要打包套件,必须先安装 rpm-build 套件 sudo yum install rpm-build 2.建立打包套件的环境 sudo yum install fedora-rpmdevtools 接著执行 fedora-buildrpmtree 来建立打包的环境 fedora-buildrpmtree 执行完后,在 Home 目录底下就产生 rpmbuild 的目录 BUILD 编译时所用的暂存目录 -bp 只作准备 (解压与打补丁) -bc 准备并编译 -bi 编译并安装 -bl 检验文件是否齐全 -ba 编译后做成*.rpm和src.rpm -bb 编译后做成*.rpm -bs 只做成*.src.rpm -tc -ti -ta -tb -ts 的功能类似,只是所需参数由spec文件变成tar包。 3.建立 ~/.rpmmacros 档案 %_topdir %(echo $HOME)/rpmbuild 如果有 GPG Key 可以加上类似底下几行,到时候要 GPG Sign 时会用到: %_signature gpg 二、建立 spec 档案 cd ~/rpmbuild/SPECS 1.利用 fedora-newrpmspec 工具程式来产生一个 spec 档的样本,然后再慢慢来修改 fedora-newrpmspec pcmanfm 执行完后,就会产生 pcmanfm.spec 2.编辑 pcmanfm.spec Version: 0.3.0 Version Tag 及 Release Tag 的命名规则,请参考: Version Tag 要是数字才行 Release Tag for Pre-Release Packages: 格式: 0.%{X}.%{alphatag} 所以 pcmanfm-0.3.0-beta3 的 Release Tag 就是 0.1.beta3 2.2.Group、License、URL、Source、Patch 及 BuildRoot Group: Applications/System Group 部份请参考: Source 部份,最好是包含整个网址,而不要只有档名而已 必要时需要自己制作 patch 档案,例: cd ~/rpmbuild/BUILD/pcmanfm-0.3.0-beta3 2.3.BuildRequires 及 Requires BuildRequires: automake >= 1.9, gtk2-devel >= 2.6, gamin-devel BuildRequires 及 Requires 的部份就要看原作者是否有提到需要哪些套件 2.4.%description %description %description 要注意的是,每一行最长不要超过 79 个字元 2.5.%changelog %changelog %changelog 部份,就是日期、打包者的姓名及 E-mail 等等 2.6.%prep %prep %setup macro 会把 source code tarball 解开并自动进到 %{name}-%{version} 的目录中 2.7.%build %build 若有需要加 configure 的参数,可以加在 %configure 后面 2.8.%install %install 若还有其他相关的安装指令都可以加在这里 %{_datadir}/applications/fedora-pcmanfm.desktop BuildRequires 的部份也要加入 desktop-file-utils: BuildRequires: automake >= 1.9, gtk2-devel >= 2.6, gamin-devel, desktop-file-utils 另外还要加入: Requires(post): desktop-file-utils %post 及 %postun 的部份也要做处理 2.9.%clean %clean 2.10.%files %files -f %{name}.lang %files 后面的 -f %{name}.lang 则是跟 %find_lang macro 搭配 2.11.%post %post 用来处理套件安装完成后要执行的指令 2.12.%postun %postun 用来处理套件移除后要执行的指令 2.13.%pre 2.14.%preun 三、测试打包 1.rpmbuild -bc rpmbuild -bc pcmanfm.spec 像我一执行时就出现错误: checking for PACKAGE... configure: error: Package requirements (gtk+-2.0 >= 2.6. 查了一下,所需要的套件是 startup-notification-devel [candyz@candyz:~/rpmbuild/SPECS] locate libstartup-notification-1.0 因此,修改 BuildRequires 如下: BuildRequires: automake >= 1.9, gtk2-devel >= 2.6, gamin-devel, desktop-file-utils, gettext, startup-notification-devel 加进了 startup-notification-devel 2.rpmbuild -bi rpmbuild -bi pcmanfm.spec 例如我执行完的结果,看到以下的警告讯息: warning: Installed (but unpackaged) file(s) found: 因此,可以得知,%files 中还少了 /usr/bin/pcmanfm %files -f %{name}.lang 相关的 macros 可以在 http://fedoraproject.org/wiki/Extras/RPMMacros 查询到 %{_sysconfdir} /etc 请尽量改用 macros 来取代 /etc /usr/bin /usr/lib 的写法 3.rpmbuild -bs、rpmbuild -bb and rpmbuild -ba 3.1.用 rpmbuild -bs 来产生 SRPMS rpmbuild -bs pcmanfm.spec 3.2.用 rpmbuild -bb 来产生 RPMS rpmbuild -bb pcmanfm.spec 3.3.用 rpmbuild -ba 来同时产生 SRPMS 及 RPMS rpmbuild -ba pcmanfm.spec 四、使用 rpmlint 来检查 SRPMS RPMS rpmlint -i ~/rpmbuild/SRPMS/pcmanfm-0.3.0-0.1.beta3.src.rpm rpmlint 的错误讯息请参考: 五、使用 mock 来 chroot build mock -r fedora-5-i386-core.cfg ~/rpmbuild/SRPMS/pcmanfm-0.3.0-0.1.beta3.src.rpm 六、其他进阶部份 若套件有包含一些不重要的 examples 时,可以在 %install 最后的地方删除掉 请参考: 2.不需要加到 BuildRequires 中的 Exceptions bash 详细清单请参考: http://fedoraproject.org/wiki/Extras/FullExceptionList 3.Documentation 4.Configuration files 5.Macros 6.不要使用 %makeinstall macro make DESTDIR=$RPM_BUILD_ROOT install 7.Fedora RPM Development Tools 8.RPM scriptlet recipes 七、GPG Sign 2.rpm –addsign 八、参考文件 附录一、完整的 pcmanfm.spec Comments are closed |
RPM 打包技术与典型 SPEC 文件分析RPM 打包技术与典型 SPEC 文件分析
杨爱林 (alyang@redflag-linux.com), Linux 研发工程师 2005 年 7 月 01 日 本文分为两部分,第一部分阐述了 rpm 工具的功能以及 rpmbuild 工具,详细的介绍了 spec文件的书写规则以及关键部分,第二部分对一个典型的 spec 文件做了详细的分析。 RPM全称是 Red Hat Package Manager(Red Hat包管理器)。几乎所有的 Linux 发行版本都使用这种形式的软件包管理安装、更新和卸载软件。 RPM是一个开放的软件包管理系统。它工作于Red Hat Linux以及其它Linux和UNIX 系统,可被任何人使用。redhat软件公司鼓励其它厂商来了解RPM并在自己的产品中使用它。RPM的发布基于GPL协议。对于最终用户来说,使用 RPM所提供的功能来维护系统是比较容易和轻松的。安装、卸载和升级RPM软件包只需一条命令就可以搞定。RPM维护了一个所有已安装的软件包和文件的数 据库,可以让用户进行查询和验证工作。在软件包升级过程中,RPM会对配置文件进行特别处理,绝对不会丢失以往的定制信息。对于程序员RPM可以让我们连 同软件的源代码打包成源代码和二进制软件包供最终用户使用。 RPM拥有功能强大的查询选项。我们可以搜索数据库来查询软件包或文件。也可以查出某个文件属于哪个软件包或出自哪儿。RPM软件包中的文件是以压缩格式存放的,拥有一个定制的二进制头文件,其中包含有关包和内容的信息,可以让我们对单个软件包的查询简便又快速。 RPM另一个强大的功能是进行软件包的验证。如果我们担心误删了某个软件包中的某个文件,我们就可以对它进行验证。任何非正常现象将会被通知。如果需要的话还可以重新安装该软件包。在重新安装过程中,所有被修改过的配置文件将被保留。 RPM设计目标之一就是要保持软件包的原始特征, 就象该软件的原始发布者发布软件时那样。通过使用RPM我们可以拥有最初的软件和最新的补丁程序,还有详细的软件构建信息。 概括的说:RPM有五种基本的操作功能(不包括创建软件包):安装、卸载、升级、查询、和验证。关于rpm命令的使用我们可以用以下命令: [root@hostname root]rpm -help 来获的。 1) 安装 rpm -i ( or --install) options file1.rpm ... fileN.rpm 通过rpm -ivh可以把rpm软件包安装到系统中,当然也可以使用不同的参数选项,笔者建议使用-ivh ,使用该选项可以解决大部分rpm软件包的安装,至于详细的参数说明可用查看rpm的man 文档。 2 )删除 rpm -e ( or --erase) options pkg1 ... pkgN 如果某个软件包你再也不想使用了,那就用以上这个命令彻底的把你指定的rpm软件包清除掉把。 3 )升级 rpm -U ( or --upgrade) options file1.rpm ... fileN.rpm 由于开源软件更新速度快,用户当然要使用最新版本的软件包,此时最合适的就是rpm升级功能,当然最理想的参数选项就是-Uvh。 4 )查询 rpm -q ( or --query) options 实际上我们通常使用rpm工具最多的功能还是它的查询功能,比如查看软件包的版本、依赖关系等软件包的详细说明都要用到。最有用的参数选项是-qpi。 5 )校验已安装的软件包 rpm -V ( or --verify, or -y) options 一般我们可用通过该命令来验证已安装软件包,根据笔者的经验该命令一般没什么用途,只做一个了解就ok了。 能熟练掌握以上命令以及部分参数含义,管理日常的rpm软件包就不成问题了。然而随着Linux风靡全球,越来越多的开发者喜欢采用RPM格式来发布自己的软件包。那么RPM软件包是怎样制作的呢?对大多数Linux开发工程师来说是比较陌生的。 其实,制作RPM软件包并不是一件复杂的工作,其中的关键在于编写SPEC软件包描述文件。要想制作一个rpm软件包就必须写一个软件包描述文件 (SPEC)。这个文件中包含了软件包的诸多信息,如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要 包含的文件列表等等。 描述文件说明如下: (1) 文件头 一般的spec文件头包含以下几个域: Summary: Name: Version: Release: Vendor: Copyright: Group: Source: %description: (2)%prep段 这个段是预处理段,通常用来执行一些解开源程序包的命令,为下一步的编译安装作准备。%prep和下面的%build,%install段一样,除 了可以执行RPM所定义的宏命令(以%开头)以外,还可以执行SHELL命令,命令可以有很多行,如我们常写的tar解包命令。 (3)build段 本段是建立段,所要执行的命令为生成软件包服务,如make 命令。 (4)%install段 本段是安装段,其中的命令在安装软件包时将执行,如make install命令。 (5)%files段 本段是文件段,用于定义软件包所包含的文件,分为三类--说明文档(doc),配置文件(config)及执行程序,还可定义文件存取权限,拥有者及组别。 (6)%changelog段 本段是修改日志段。你可以将软件的每次修改记录到这里,保存到发布的软件包中,以便查询之用。每一个修改日志都有这样一种格式:第一行是:* 星期 月 日 年 修改人 电子信箱。其中:星期、月份均用英文形式的前3个字母,用中文会报错。接下来的行写的是修改了什么地方,可写多行。一般以减号开始,便于后续的查阅。 如果想发布rpm格式的源码包或者是二进制包,就要使用rpmbuild工具(rpm最新打包工具)。如果我们已经根据本地源码包的成功编译安装而 写了spec文件(该文件要以.spec结束),那我们就可以建立一个打包环境,也就是目录树的建立,一般是在/usr/src/redhat/目录下建 立5个目录。它门分别是BUILD、SOURCE、SPEC、SRPM、RPM。其中BUILD目录用来存放打包过程中的源文件,SOURCE用来存放打 包是要用到的源文件和patch,SPEC用来存放spec文件,SRPM、RPM分别存放打包生成的rpm格式的源文件和二进制文件。当然我们可以根据 需要来选用不同的参数打包文件,笔者总结如下3条。 1) 只生成二进制格式的rpm包
生成的文件会在刚才建立的RPM目录下存在。 2)只生成src格式的rpm包 rpmbuild -bs xxx.spec 生成的文件会在刚才建立的SRPM目录下存在。 3) 只需要生成完整的源文件 rpmbuild -bp xxx.spec 源文件存在目录BUILD下。 读者朋友可能对这个命令不太明白,这个命令的作用就是把tar包解开然后把所有的补丁文件合并而生成一个完整的具最新功能的源文件。 4) 完全打包 rpmbuild -ba xxx.spec 产生以上3个过程分别生成的包。存放在相应的目录下。 软件包制作完成后可用rpm命令查询,看看效果。如果不满意的话可以再次修改软件包描述文件,重新运行以上命令产生新的RPM软件包。
通过第一部分的介绍,我们对软件包的管理以及spec文件的一些细节应该掌握的差不多了,接下来通过分析kaffeine.spec(kaffeine是linux平台下的媒体播放器)文件来让读者朋友实践一回spec文件的规范和书写。 Kaffeine.spec文件内容如下:
以上这部分就是我们第一部分所说的文件头。这一部分主要包括软件包的名称、版本、源代码和patch等信息,通过这些关键字我们可以一目了然。查看以上内容,我们会全面了解该软件包。 接下来的这一个段就是核心部分,涉及到解包、补丁、编译、安装的过程。
这部分内容与所要打的包有关系,我们要根据具体情况来写出编译过程。这部分内容是最复杂的内容,当然,我们也可以看出,这样的写法其实就是在写一种规范化的脚本,说到脚本,读者朋友门就应该领会到这部分内容的灵活性了。
这部分内容可以说是spec文件的最后内容了,它对团队软件开发以及后续的软件维护至关重要,它相当于一个日志,记录了所有的基于该软件包的修改、更新信息。
在Linux下RPM软件包的管理与RPM软件包的制作关键在rpm工具的使用和spec描述文件的起草。要想制作一个RPM格式的软件包必须编写 软件包描述文件。其标准命名格式为:软件名-版本号-释出号.spec,这个文件详细描述了有关该软件包的诸多信息,如软件名,版本,类别,说明摘要,创 建时要执行什么指令,安装时要执行什么操作,以及软件包所要包含的文件等等。有了这个文件RPM就可以制作出相应的rpm软件包。
|
[转载] rpm 打包教學
原创者为Kaio 因為是我寫的,所以沒有版權問題,歡迎留名轉貼。 ![]() 這是 copy-and-paste 過來的,有些地方的超連結丢了,也有些排版也可能看得不太舒服,這裏可以得到原版: https://fedoraproject.org/wiki/Zh/Do...95%99%E5%AD%B8 Fedora 打包教學 閲讀注意事項 * 本指南是以 Fedora 8 為基礎,並不保證能在其他版本上實作。 * 如果沒有注明需要管理目帳號的命令,一律以個人帳號執行。 * 一切因為依照以下操作步驟而引致任何損失,本文所有參與編輯者恕不負責。 前言 這不是一篇完整的 RPM 打包參考文,而是一篇中文的打包導引文。您不能期望單純的從這篇文章中找到所有打包應用到的知識與技巧,這裏提供的只是概略筆者以自己經驗歸納出的打包過 程;世上高手何其多,網上文檔何其精,筆者非常鼓勵大家多參考多思考多實作。請緊學習包含吸收知識與實踐,缺一不可,邊做邊學才能算是實務、才能算是學 習;多看文檔、虚心發問、享受過程、累積成果。 推薦參考文章 * Maximum RPM * Packaging Guidelines * Valid RPM Macros * Jason Corley's RPM Macros Table 事前準備工作 1. 安裝 rpmbuild、rpmdevtools、rpmlint 包。 rpmbuild 是執行打包的工具包, rpmdevtools 是提高打包後勤工作效率的工具包, rpmlint 為檢查 spec 規格檔案正確性的工具包。 2. 執行 rpmdev-setuptree ,打包用檔案系統 rpmbuild/{BUILD,RPMS SOURCES,SPECS,SRPMS} 會在 ~/ 被自動建立。 3. 移到 ~/rpmbuile/SPECS/ ,執行 rpmdev-newspec 。一個新的 spec 規格檔案會被自動建立,它是一個純文字檔,裏面包含各種對 RPM 安裝包詳細設定;設定包括軟件本身的資訊、編譯/安裝/移除步驟、修改記錄等等内容。 4. [請進入下一部分] 編輯 spec 規格檔案 以下是剛打包的 emesene RPM 的 .spec 檔案。因為它不可能包含所有會用到的東西,所以只可以作為參考;在裏面作了大量的注解,應該可以幫助瞭解大致結構: 定義這些路徑的原因是省略 SPEC 檔接下來會用到的篇幅。 %define appdir %{_datadir}/%{name} 一些 %{__abc} 的是系統常用工具的macro,這樣做能令系統在安裝該 RPM 時才找出工具的位置,防止工具儲存位置的更改。 %install 包裝 SRPM 測試源碼包 1. 在 ~/rpmbuild/SPECS 執行 rpmbuild -ba 你的軟件名稱.specs ,測試包裝 RPM 和 SRPM 包(也可以只執行 rpmbuild -bs 你的軟件名稱.specs 只測試 SRPM 包) 2. 如有包裝期間有錯誤回饋或發生其他問題,可以檢查 ~/rpmbuild/SOURCES 內的檔案、 .spec 檔、或執行 rpmbuild -bp 你的軟件名稱.specs 後檢查 ~/rpmbuild/BUILD 內的檔案。 3. 其實有比較懶惰的辦法(在從 cvs 伺服器 check out 出來文件夾內以 make [command] 做相同的動作,只是要有全部重新 check out 的心理準備);請在 cvs check out 出來的文件夾內輸入 make help 獲得更多資訊。 4. [請進入下一部分] 新包審批程序 一個軟件進入 Fedora 的 repository 讓公眾更新是需要經過一系列的審批程序的。 1. 確保 SRPM 源碼準備好。(用 rpmlint 檢查 .spec 規格檔) 2. 在 Red Hat 的 Bugzilla 系統建立一個新的 Bug 檔案。 3. 經過 Fedora 審批人確保 SRPM 源碼包符合標準後,會在 Bug 內授與一個審批通過的 fedora‑review ACK+ 。 4. 最後包裝人可以向有關有 cvs 管理權限的人員要求(把 fedora‑cvs flag 調成 + ),在 Fedora repository 建立一該軟件的 tree。 5. [請進入下一部分] 匯入 SRPM 源碼包 1. 進入從 cvs 那裏 check out 的文件夾 e.g. ~/src/fedora/rpms/你的軟件名稱/common/ ,執行 ./cvs-import.sh 你的SRPM檔案名稱 ,將源碼和相關檔案匯入到本地的 cvs 文件夾。 2. [請進入下一部分] 正式編譯 RPM 安裝包 1. 檢查所有檔的正確性。 2. 確定所有相關檔案都經已上傳至 cvs 伺服器(或其他伺服器):(所有來自作者/官方網站的源碼包,最好是自動包裝過程中從來源服務器實時下載;否則由於源碼檔案有可能過大,不適合上傳到 cvs 伺服器影響效率。應該把它們上傳至個別設置的源碼檔案眝存伺服器: make upload FILES=[源碼包檔案名稱] (如要清除伺伺器上舊有的源碼檔碼檔案,第一個上傳的檔案要執行以下命令: make new-sources FILES=[源碼包檔案名稱] ),再把 source 和 .cvsignore 兩個檔案 check in 到 cvs 伺服器上。) 3. 執行 make tag 建立新的 tag 標簽。tag 標簽用於標示所有 RPM 安裝包有關的檔案,附有 checksum 以對照檔案的狀態。如果希望保留發行版本號 (n-v-r 的 r),除第一次建立 tag 標簽,可執行 make force-tag 覆蓋最新建立的 tag 標簽。 4. 如一切順利,執行 make build ,RPM 安裝包將會在中央包裝系統(正在服役的系統名稱: Koji)。 5. 看到文字介面訊息中看到所有工作為 done 後,代表 RPM 和 SRPM 等檔案已經被建立,正在為中央包裝系統所儲存。 6. [請進入下一部分] 遞送到發行版本 ( Rawhide / 開發版本不用進行以下步驟) 1. 開啟並以 Fedora 帳號登入 Bodhi (發行版本遞送系統)。 2. 在左邊頁面按下 New Update ,把空格填上: Package = n-v-r 格式的包版本編號、 Release = 要遞送的發行版本、 Type = 更新種類( bugfix 是補錯, enhancement 是改進, security 是保安)、Request = 要遞送的要求( Testing 是測試 repository ,一般都先到那裏讓有興趣幫忙測試的人下載; Stable 是穏定 repository ,就是公眾使用者都能下載的,一般要先經過 testing 一段短時間沒有問題後才到那裏; None 是還沒準備好遞送的,暫時存檔。)、 Bugs = 和此遞送有關的 bug 。若右邊空格選取,當更新遞送到 Stable ,系統會自動關閉該 bug 、 Notes = 備注、 Suggest Reboot 空格是要求使用者更新後重新啟動電腦。 3. [完成!] 後輟 本文仍有很大的改進空間,歡迎提供任何意見,甚至動手修改完善。謝謝您的閲讀! 最後修改: Kaio 13:23, 7 February 2008 (HKT) 作者原文: http://keimoto.net/wiki/index.php/Fe...95%99%E5%AD%B8 作者 Blog 已遷到: http://blog.dejieshi.com Retrieved from "https://fedoraproject.org/wiki/Zh/Do...95%99%E5%AD%B8" |
1-3 of 3