RPM Building

Catalog

  • RPM 套件打包入门 一、准备工作 1.要打包套件，必须先安装 rpm-build 套件 sudo yum install rpm-build 2.建立打包套件的环境在 FC5 后，并不建议用 root 来打包套件，所以请改用一般的使用者身分来打包套件首先要安装 fedora-rpmdevtools 这个套件 sudo yum install fedora ...
    Posted Dec 8, 2008, 8:25 AM by Liang Suilong
  • RPM 打包技术与典型 SPEC 文件分析RPM 打包技术与典型 SPEC 文件分析 杨爱林 (alyang@redflag-linux.com), Linux 研发工程师2005 年 7 月 01 日本文分为两部分，第一部分阐述了 rpm 工具的功能以及 rpmbuild 工具，详细的介绍了 spec文件的书写规则以及关键部分，第二部分对一个典型的 spec 文件做了详细的分析。 一 、rpm 介绍 1. 概述 RPM全称是 ...
    Posted Dec 8, 2008, 8:20 AM by Liang Suilong
  • [转载] rpm 打包教學 原创者为Kaio因為是我寫的，所以沒有版權問題，歡迎留名轉貼。 這是 copy-and-paste 過來的，有些地方的超連結丢了，也有些排版也可能看得不太舒服，這裏可以得到原版: https://fedoraproject.org/wiki/Zh/Do...95%99%E5%AD%B8 Fedora 打包教學 閲讀注意事項 * 本指南是以 Fedora 8 為基礎 ...
    Posted Feb 18, 2009, 10:44 AM by Liang Suilong
Showing posts 1 - 3 of 3. View more »

Subscribe to posts

RPM 套件打包入门

posted Dec 8, 2008, 8:17 AM by Liang Suilong

一、准备工作

1.要打包套件，必须先安装 rpm-build 套件

sudo yum install rpm-build

2.建立打包套件的环境
在 FC5 后，并不建议用 root 来打包套件，所以请改用一般的使用者身分来打包套件
首先要安装 fedora-rpmdevtools 这个套件

sudo yum install fedora-rpmdevtools

接著执行 fedora-buildrpmtree 来建立打包的环境

fedora-buildrpmtree

执行完后，在 Home 目录底下就产生 rpmbuild 的目录
在 rpmbuild 目录底下又有 BUILD RPMS SOURCES SPECS SRPMS 五个子目录

BUILD 编译时所用的暂存目录
RPMS 放置打包好的套件
SOURCES 放置套件的原始码及修补档等等
SPECS 放置 .spec 档
SRPMS 放置 Source RPMS (.src.rpm)

-bp 只作准备 （解压与打补丁）

-bc 准备并编译

-bi 编译并安装

-bl 检验文件是否齐全

-ba 编译后做成*.rpm和src.rpm

-bb 编译后做成*.rpm

-bs 只做成*.src.rpm

-tc -ti -ta -tb -ts 的功能类似，只是所需参数由spec文件变成tar包。

3.建立 ~/.rpmmacros 档案
编辑 ~/.rpmmacros，主要是设定 %packager 及 %vendor 等等:

%_topdir %(echo $HOME)/rpmbuild
%_smp_mflags -j3
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
%packager Chung-Yen Chang <candyz0416@gmail.com>
%vendor Chinese Linux Extensions

如果有 GPG Key 可以加上类似底下几行，到时候要 GPG Sign 时会用到:

%_signature gpg
%_gpg_path ~/.gnupg
%_gpg_name Chung-Yen Chang (candyz) <candyz0416@gmail.com>
%_gpgbin /usr/bin/gpg

二、建立 spec 档案
我以打包 pcmanfm-0.3.0-beta3.tar.gz 为例
假设这个套件没有人打包过，因此必须自行建立 pcmanfm.spec 档案
先进到 ~/rpmbuild/SPECS 目录底下:

cd ~/rpmbuild/SPECS

1.利用 fedora-newrpmspec 工具程式来产生一个 spec 档的样本，然后再慢慢来修改

fedora-newrpmspec pcmanfm

执行完后，就会产生 pcmanfm.spec
spec 档的命名规则为 %{name}.spec
spec 档的 Encoding 必须为 UTF-8

2.编辑 pcmanfm.spec
2.1.Version、Release 及 Summary

Version: 0.3.0
Release: 0.1.beta3%{?dist}
Summary: PCMan File Manager

Version Tag 及 Release Tag 的命名规则，请参考:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines

Version Tag 要是数字才行
pcmanfm-0.3.0-beta3 算是 Pre-release packages
(Version 中包含 “alpha”, “beta”, “rc”, “cvs”)
我们不能直接用在 Version 中，beta3 的部份要改放到 Release 中

Release Tag for Pre-Release Packages:

格式: 0.%{X}.%{alphatag}
0 不变
%{X} 从 1 开始递增
%{alphatag} 来自於 Version Tag 中的字串

所以 pcmanfm-0.3.0-beta3 的 Release Tag 就是 0.1.beta3
至於后面的 Dist Tag (%{?dist}) 则是给 mock build 时用的
Dist Tag 请参考: http://fedoraproject.org/wiki/Packaging/DistTag

2.2.Group、License、URL、Source、Patch 及 BuildRoot

Group: Applications/System
License: GPL
URL: http://pcmanfm.sourceforge.net
Source0: http://jaist.dl.sourceforge.net/sourceforge/pcmanfm/pcmanfm-0.3.0-beta3.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

Group 部份请参考:
/usr/share/doc/rpm-*/GROUPS 或是 http://fedoraproject.org/wiki/RPMGroups

Source 部份，最好是包含整个网址，而不要只有档名而已
若有好几个 Source 则用 Source0 Source1 Source2 … 依此类推
若有 Patch 档就需要用到 (例: Patch0: pcmanfm-0.3.0-beta3-Makefile.patch)
若有好几个 Pacth 则用 Patch0 Patch1 Patch2 … 依此类推

必要时需要自己制作 patch 档案，例:

cd ~/rpmbuild/BUILD/pcmanfm-0.3.0-beta3
cp Makefile Makefile.orig
然后修改 Makefile
cd ~/rpmbuild/BUILD
gendiff pcmanfm-0.3.0-beta3 .Makefile < ../SOURCES/pcmanfm-0.3.0-beta3-Makefile.patch

2.3.BuildRequires 及 Requires

BuildRequires: automake >= 1.9, gtk2-devel >= 2.6, gamin-devel
Requires: gtk2 >= 2.6, gamin

BuildRequires 及 Requires 的部份就要看原作者是否有提到需要哪些套件
不然，就得从 mock build 时的 build.log 中
慢慢去找出所需要的 BuildRequires 及 Requires

2.4.%description

%description
PCMan File Manager
An extremly fast and lightweight file manager which features tabbed browsing
and user-friendly interface
Features:
Extremly fast and lightweight
Can be started in one second on normal machine
Tabbed browsing (Similar to Firefox)
Drag & Drop support
Files can be dragged among tabs
Load large directories in reasonable time
File association support (Default application)
Basic thumbnail support
Bookmarks support
Handles non-UTF-8 encoded filenames correctly
Provide icon view and detailed list view
Standard compliant (Follows FreeDesktop.org)
Clean and user-friendly interface (GTK+ 2)

%description 要注意的是，每一行最长不要超过 79 个字元

2.5.%changelog

%changelog
* Fri Aug 18 2006 Chung-Yen Chang <candyz0416@gmail.com> - 0.3.0-0.1.beta3
- Initial RPM release

%changelog 部份，就是日期、打包者的姓名及 E-mail 等等
最后面则是要包含这次的 %{version}-%{release}
若有使用 Epoch Tag 则是 %{Epoch}:%{version}-%{release}

2.6.%prep

%prep
%setup -q -n pcmanfm-0.3.0-beta3

%setup macro 会把 source code tarball 解开并自动进到 %{name}-%{version} 的目录中
因为我们把 Version Tag 0.3.0-beta3 的 beta3 拆到 Release Tag 去
Version Tag 变成 0.3.0，所以 %setup 在 rpmbuild 时会出问题
rpmbuild 会解开 pcmanfm-0.3.0-beta3.tar.gz 并试著进到 pcmanfm-0.3.0 (%{name}-%{version}) 的目录中
但实际上应该是要进到 pcmanfm-0.3.0-beta3 的目录才对
因此，我们必须加上 -n pcmanfm-0.3.0-beta3 来解决这个问题
若有 Source2 Source5 等等的 tarball 同时也要解开时，可以使用 -a 参数来指定 (例: %setup -q -a 2 -a 5)
若有 Patch 档则同样在这里做处理 (例: %patch1 -p1 -b .bak)
其他一些在正式 build (make) 前要做的特殊处理，都可以在这里做
(例: find . -name \*.h -o -name \*.c | xargs chmod ugo-x)

2.7.%build

%build
%configure
make %{?_smp_mflags}

若有需要加 configure 的参数，可以加在 %configure 后面
(例: %configure –prefix=%{_prefix})
若还有其他的编译指令需要执行时，都可以加在这里

2.8.%install

%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
%find_lang %{name}
desktop-file-install \
--delete-original \
--vendor fedora \
--dir ${RPM_BUILD_ROOT}/%{_datadir}/applications \
--add-category X-Fedora \
${RPM_BUILD_ROOT}/%{_datadir}/applications/pcmanfm.desktop

若还有其他相关的安装指令都可以加在这里
至於 locale mo 档的部份，则是要改用 %find_lang macro 来处理
另外，关於 desktop 档的部份，要在 %install 中使用 desktop-file-install 来处理
然后在 %files 中加入一行:

%{_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
Requires(postun): desktop-file-utils

%post 及 %postun 的部份也要做处理
Desktop files 请参考: http://fedoraproject.org/wiki/Packaging/Guidelines#desktop

2.9.%clean

%clean
rm -rf $RPM_BUILD_ROOT

2.10.%files

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO
%{_datadir}/applications/fedora-pcmanfm.desktop

%files 后面的 -f %{name}.lang 则是跟 %find_lang macro 搭配
用来处理 locale mo 档
%doc 部份，则是放 AUTHORS COPYING ChangeLog INSTALL NEWS README TODO 等文件
至少要放版权的部份 (如 License: GPL 则 COPYING 的内容就是放 GPL 版权的内容)
若不知道还会安装哪些档案也没关系，之后可以利用 rpmbuild -bi 的 log 来查询

2.11.%post

%post
update-desktop-database %{_datadir}/applications >/dev/null 2>&1 || :

用来处理套件安装完成后要执行的指令
例如 update-desktop-database 那行就是在处理 Desktop files 部份

2.12.%postun

%postun
update-desktop-database %{_datadir}/applications >/dev/null 2>&1 || :

用来处理套件移除后要执行的指令
例如 update-desktop-database 那行就是在处理 Desktop files 部份

2.13.%pre
用来处理套件安装前要执行的指令
在本例中没有用到

2.14.%preun
用来处理套件移除前要执行的指令
在本例中没有用到

三、测试打包
除了 %files 的部份还没完全处理完外，其他部份大致上都没问题了

1.rpmbuild -bc
rpmbuild -bc 会从一开始一直做到 %build 为止
用来检查到 %build 为止是否还有问题
若有发现任何错误，如 command not found 等等
就要去 check required package 然后加到 Requires/BuildRequires 中

rpmbuild -bc pcmanfm.spec

像我一执行时就出现错误:

checking for PACKAGE... configure: error: Package requirements (gtk+-2.0 >= 2.6.
0 gthread-2.0 libstartup-notification-1.0) were not me
t:
No package ´libstartup-notification-1.0´ found

查了一下，所需要的套件是 startup-notification-devel

[candyz@candyz:~/rpmbuild/SPECS] locate libstartup-notification-1.0
/usr/lib/pkgconfig/libstartup-notification-1.0.pc
[candyz@candyz:~/rpmbuild/SPECS] rpm -qf /usr/lib/pkgconfig/libstartup-notification-1.0.pc
startup-notification-devel-0.8-3.2.1

因此，修改 BuildRequires 如下:

BuildRequires: automake >= 1.9, gtk2-devel >= 2.6, gamin-devel, desktop-file-utils, gettext, startup-notification-devel

加进了 startup-notification-devel
而多加了 gettext 则是给 mock build 用的
因为在 mock build 时会去 check 是否有 gettext，有才会去执行 %find_lang macro

2.rpmbuild -bi
rpmbuild -bi 会从一开始一直做到 %install 为止

rpmbuild -bi pcmanfm.spec

例如我执行完的结果，看到以下的警告讯息:

warning: Installed (but unpackaged) file(s) found:
/usr/bin/pcmanfm
/usr/share/applications/pcmanfm.desktop
/usr/share/locale/ca/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/de/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/es/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/fr/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/hu/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/it/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/pl/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/pt_BR/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/ru/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/sv_SE/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/zh_CN/LC_MESSAGES/pcmanfm.mo
/usr/share/locale/zh_TW/LC_MESSAGES/pcmanfm.mo

因此，可以得知，%files 中还少了 /usr/bin/pcmanfm
至於 locale 的 mo 档部份，可以不用管，改交给 %find_lang macro 去处理了
而 /usr/share/applications/pcmanfm.desktop 则改由 desktop-file-install 处理
因此，修改后的 %files 部份如下:

%files -f %{name}.lang
%defattr(-,root,root,-)
%doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO
%{_bindir}/pcmanfm
%{_datadir}/applications/fedora-pcmanfm.desktop

相关的 macros 可以在 http://fedoraproject.org/wiki/Extras/RPMMacros 查询到
常见的如:

%{_sysconfdir} /etc
%{_initrddir} %{_sysconfdir}/rc.d/init.d
%{_prefix} /usr
%{_exec_prefix} %{_prefix}
%{_bindir} %{_exec_prefix}/bin
%{_lib} lib
%{_libdir} %{_exec_prefix}/%{_lib}
%{_libexecdir} %{_exec_prefix}/libexec
%{_sbindir} %{_exec_prefix}/sbin
%{_sharedstatedir} %{_prefix}/com
%{_datadir} %{_prefix}/share
%{_includedir} %{_prefix}/include
%{_oldincludedir} /usr/include
%{_var} /var
%{_tmppath} %{_var}/tmp

请尽量改用 macros 来取代 /etc /usr/bin /usr/lib 的写法

3.rpmbuild -bs、rpmbuild -bb and rpmbuild -ba
若 rpmbuild -bi 都没错误，接下来就可以开始打包套件了

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 -i ~/rpmbuild/RPMS/i386/pcmanfm-*.rpm

rpmlint 的错误讯息请参考:
http://fedoraproject.org/wiki/ParagNemade/CommonRpmlintErrors
及 http://fedoraproject.org/wiki/Packaging/CommonRpmlintIssues

五、使用 mock 来 chroot build
mock 是一个 Chroot Build Tools
关於 mock 的安装、设定及使用请参考: http://blog.candyz.org/20060818/1307

mock -r fedora-5-i386-core.cfg ~/rpmbuild/SRPMS/pcmanfm-0.3.0-0.1.beta3.src.rpm

六、其他进阶部份
1.devel subpackage
所有的可执行档及 *.so.* 要放在 main package
而所有的 headers, static libraries, libtool archives, *.so files, autotools,
and pkgconfig files 则要放在 -devel subpackage.

若套件有包含一些不重要的 examples 时，可以在 %install 最后的地方删除掉
把 examples 改放到 -devel 的 %doc 中

请参考:
http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide 的范例

2.不需要加到 BuildRequires 中的 Exceptions

bash
bzip2
coreutils
cpio
diffutils
fedora-release (and/or redhat-release)
gcc
gcc-c++
gzip
make
patch
perl
redhat-rpm-config
rpm-build
sed
tar
unzip
which

详细清单请参考: http://fedoraproject.org/wiki/Extras/FullExceptionList

3.Documentation
若有相关的说明文件，可以独立成 -doc subpackage
并以 Documentation 当作 Group Tag

4.Configuration files
设定档请使用 %config(noreplace) 来代替 %config
只有当设定档有变时，才改用 %config 来覆盖掉旧的

5.Macros
详细的 Macros 请参考: http://fedoraproject.org/wiki/Extras/RPMMacros

6.不要使用 %makeinstall macro
直接用:

make DESTDIR=$RPM_BUILD_ROOT install

7.Fedora RPM Development Tools
fedora-rpmdevtools，请参考: http://fedoraproject.org/wiki/fedora-rpmdevtools

8.RPM scriptlet recipes
关於 %pre %post %preun %postun 的用法及注意事项，请参考:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets

七、GPG Sign
1.rpmbuild –sign
在执行 rpmbuild 时加上 –sign 的参数

2.rpm –addsign
若在 rpmbuild 时没有使用 –sign 参数，也可以事后再用 rpm –addsign 来 Sign 套件

八、参考文件
http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide
http://koti.welho.com/vskytta/packagers-handbook/packagers-handbook.html
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/ParagNemade/PackagingNotes
http://www.rpm.org/max-rpm/

附录一、完整的 pcmanfm.spec
pcmanfm.spec

Comments are closed

RPM 打包技术与典型 SPEC 文件分析RPM 打包技术与典型 SPEC 文件分析

posted Dec 8, 2008, 8:17 AM by Liang Suilong

杨爱林 (alyang@redflag-linux.com), Linux 研发工程师

2005 年 7 月 01 日

本文分为两部分，第一部分阐述了 rpm 工具的功能以及 rpmbuild 工具，详细的介绍了 spec文件的书写规则以及关键部分，第二部分对一个典型的 spec 文件做了详细的分析。

一 、rpm 介绍

1. 概述

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

来获的。

2．RPM工具功能

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了。

3．spec文件规范

能熟练掌握以上命令以及部分参数含义，管理日常的rpm软件包就不成问题了。然而随着Linux风靡全球，越来越多的开发者喜欢采用RPM格式来发布自己的软件包。那么RPM软件包是怎样制作的呢？对大多数Linux开发工程师来说是比较陌生的。

其实，制作RPM软件包并不是一件复杂的工作，其中的关键在于编写SPEC软件包描述文件。要想制作一个rpm软件包就必须写一个软件包描述文件 （SPEC）。这个文件中包含了软件包的诸多信息，如软件包的名字、版本、类别、说明摘要、创建时要执行什么指令、安装时要执行什么操作、以及软件包所要 包含的文件列表等等。

描述文件说明如下：

（1） 文件头

一般的spec文件头包含以下几个域：

Summary：
用一句话概括该软件包尽量多的信息。

Name：
软件包的名字，最终RPM软件包是用该名字与版本号，释出号及体系号来命名软件包的。

Version：
软件版本号。仅当软件包比以前有较大改变时才增加版本号。

Release：
软件包释出号。一般我们对该软件包做了一些小的补丁的时候就应该把释出号加1。

Vendor：
软件开发者的名字。

Copyright：
软件包所采用的版权规则。具体有：GPL（自由软件），BSD，MIT，Public Domain（公共域），Distributable（贡献），commercial（商业），Share（共享）等，一般的开发都写GPL。

Group：
软件包所属类别，具体类别有：
Amusements/Games （娱乐/游戏）
Amusements/Graphics（娱乐/图形）
Applications/Archiving （应用/文档）
Applications/Communications（应用/通讯）
Applications/Databases （应用/数据库）
Applications/Editors （应用/编辑器）
Applications/Emulators （应用/仿真器）
Applications/Engineering （应用/工程）
Applications/File （应用/文件）
Applications/Internet （应用/因特网）
Applications/Multimedia（应用/多媒体）
Applications/Productivity （应用/产品）
Applications/Publishing（应用/印刷）
Applications/System（应用/系统）
Applications/Text （应用/文本）
Development/Debuggers （开发/调试器）
Development/Languages （开发/语言）
Development/Libraries （开发/函数库）
Development/System （开发/系统）
Development/Tools （开发/工具）
Documentation （文档）
System Environment/Base（系统环境/基础）
System Environment/Daemons （系统环境/守护）
System Environment/Kernel （系统环境/内核）
System Environment/Libraries （系统环境/函数库）
System Environment/Shells （系统环境/接口）
User Interface/Desktops（用户界面/桌面）
User Interface/X （用户界面/X窗口）
User Interface/X Hardware Support （用户界面/X硬件支持）

Source：
源程序软件包的名字。如 stardict-2.0.tar.gz。

%description：
软件包详细说明，可写在多个行上。

（2）%prep段

这个段是预处理段，通常用来执行一些解开源程序包的命令，为下一步的编译安装作准备。%prep和下面的%build，%install段一样，除 了可以执行RPM所定义的宏命令（以%开头）以外，还可以执行SHELL命令，命令可以有很多行，如我们常写的tar解包命令。

（3）build段

本段是建立段，所要执行的命令为生成软件包服务，如make 命令。

（4）%install段

本段是安装段，其中的命令在安装软件包时将执行，如make install命令。

（5）%files段

本段是文件段，用于定义软件包所包含的文件，分为三类--说明文档（doc），配置文件（config）及执行程序，还可定义文件存取权限，拥有者及组别。

（6）%changelog段

本段是修改日志段。你可以将软件的每次修改记录到这里，保存到发布的软件包中，以便查询之用。每一个修改日志都有这样一种格式：第一行是：* 星期 月 日 年 修改人 电子信箱。其中：星期、月份均用英文形式的前3个字母，用中文会报错。接下来的行写的是修改了什么地方，可写多行。一般以减号开始，便于后续的查阅。

4．打包

如果想发布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包
rpmbuild -bb xxx.spec
用此命令生成软件包，执行后屏幕将显示如下信息：（每行开头为行号）

1 Executing： %prep
2 + umask 022
3 + cd /usr/src/dist/BUILD
4 + exit 0
5 Executing： %build
6 + umask 022
7 + cd /usr/src/dist/BUILD

生成的文件会在刚才建立的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文件分析

通过第一部分的介绍，我们对软件包的管理以及spec文件的一些细节应该掌握的差不多了，接下来通过分析kaffeine.spec（kaffeine是linux平台下的媒体播放器）文件来让读者朋友实践一回spec文件的规范和书写。

Kaffeine.spec文件内容如下：

%define debug_package %{nil}
Name:         kaffeine
Version:        0.4.3
Release:        25
Summary:        A xine-based Media Player for KDE
Group:          Applications/Multimedia
License:        GPL
URL:            http://kaffeine.sourceforge.net/
Source0:        kaffeine-0.4.3.tar.bz2
Source1:        logo.png
Source2:	icon.tgz
Source3:        kaffeine.desktop
Source4:        codecs.tgz
Patch: kaffeine-0.4.3-fix-hide-crash.patch
Patch1:kaffeine-0.4.3-without-wizard.patch
BuildRoot:      /var/tmp/kaffeine-root
%description
Kaffeine is a xine based media player for KDE3. It plays back CDs,
DVDs, and VCDs. It also decodes multimedia files like AVI, MOV, WMV,
and MP3 from local disk drives, and displays multimedia streamed over
the Internet. It interprets many of the most common multimedia formats
available - and some of the most uncommon formats, too. Additionally,
Kaffeine is fully integrated in KDE3, it supports Drag and Drop and
provides an editable playlist, a bookmark system, a Konqueror plugin,
a Mozilla plugin, OSD an much more.

以上这部分就是我们第一部分所说的文件头。这一部分主要包括软件包的名称、版本、源代码和patch等信息，通过这些关键字我们可以一目了然。查看以上内容，我们会全面了解该软件包。

接下来的这一个段就是核心部分，涉及到解包、补丁、编译、安装的过程。

%prep
%setup -q
%patch -p1
%patch1 -p1
%Build
make -f admin/Makefile.common cvs
./configure --prefix=/usr
make
#for mo files
pushd po
rm *.gmo
make
popd
%install
mkdir -p $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/share/services
cp $RPM_BUILD_ROOT/usr/share/apps/kaffeine/mms.protocol $RPM_BUILD_ROOT/usr/share/services
cp $RPM_BUILD_ROOT/usr/share/apps/kaffeine/rtsp.protocol $RPM_BUILD_ROOT/usr/share/services
#mkdir -p $RPM_BUILD_ROOT/usr/lib/firefox/plugins
#cp $RPM_BUILD_ROOT/usr/lib/kaffeineplugin/kaffeineplugin.so
$RPM_BUILD_ROOT/usr/lib/firefox/plugins
cp %{SOURCE1} $RPM_BUILD_ROOT/usr/share/apps/kaffeine
rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine.png
rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-pause.png
rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-play.png
rm -rf $RPM_BUILD_ROOT/usr/share/icons/hicolor/*/apps/kaffeine-record.png
mkdir -p $RPM_BUILD_ROOT/usr/share/icons/crystalsvg
tar zxvf %{SOURCE2} -C $RPM_BUILD_ROOT/usr/share/icons/crystalsvg
mkdir -p $RPM_BUILD_ROOT/usr/share/applnk/App/Multimedia
cp -r %{SOURCE3} $RPM_BUILD_ROOT/usr/share/applnk/App/Multimedia
mkdir -p $RPM_BUILD_ROOT/usr/lib/win32
tar zxvf %{SOURCE4} -C $RPM_BUILD_ROOT/usr/lib/win32
%clean
rm -rf $RPM_BUILD_ROOT
%post
ln -s /dev/cdrom /dev/dvd
ln -s /dev/cdrom /dev/rdvd
%files
%defattr(-,root,root)
/usr

这部分内容与所要打的包有关系，我们要根据具体情况来写出编译过程。这部分内容是最复杂的内容，当然，我们也可以看出，这样的写法其实就是在写一种规范化的脚本，说到脚本，读者朋友门就应该领会到这部分内容的灵活性了。

%changelog
* Fri Jul 1  2005 AiLin Yang <alyang@redflag-linux.com> -0.4.3-25
- modified the fullscreen bottom control panel
* Fri Jun 17 2005 xxx <xxx@redflag-linux.com> -0.4.3-24
- Modified to use xshm as video driver.
* Thu Jun 16 2005 AiLin Yang <alyang@redflag-linux.com>
- delete the option of Embed in system tray in configwidget
* Tue Jun 14 2005 AiLin Yang <alyang@redflag-linux.com>
- add fullscreen bottom control panel
- update kaffine to support my fullscreen bottom control panel

这部分内容可以说是spec文件的最后内容了，它对团队软件开发以及后续的软件维护至关重要，它相当于一个日志，记录了所有的基于该软件包的修改、更新信息。








小结

在Linux下RPM软件包的管理与RPM软件包的制作关键在rpm工具的使用和spec描述文件的起草。要想制作一个RPM格式的软件包必须编写 软件包描述文件。其标准命名格式为:软件名-版本号-释出号.spec，这个文件详细描述了有关该软件包的诸多信息,如软件名,版本,类别,说明摘要,创 建时要执行什么指令,安装时要执行什么操作,以及软件包所要包含的文件等等。有了这个文件RPM就可以制作出相应的rpm软件包。



关于作者


杨爱林，Linux 研发工程师， 通过 alyang@redflag-linux.com 可以跟他联系。

[转载] rpm 打包教學

posted Dec 4, 2008, 7:20 AM by Liang Suilong   [ updated Feb 18, 2009, 10:44 AM ]

原创者为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}
%define menudir %{_datadir}/applications
%define icondir %{_datadir}/pixmaps
%define podir   %{appdir}/po

Name:           emesene
Version:        0.99
Release:        3%{?dist}
Summary:        Instant messaging client for Windows Live Messenger (tm) network

Group:          Applications/Internet
License:        GPLv2+
URL:            http://emesene.org
Source0:        http://downloads.sourceforge.net/eme...ne-r806.tar.gz
Source1:        emesene.desktop
Patch0:         emesene-0.1-2.exec.patch
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:      noarch

BuildRequires:  desktop-file-utils, gettext
Requires:       gtk2
Requires:       gnome-python2-extras
Requires:       python

%description
emesene is an instant messaging client for Windows Live Messenger (tm) network.

%prep
%setup -q -n emesene -a0
%patch0 -p1

一些 %{__abc} 的是系統常用工具的macro，這樣做能令系統在安裝該 RPM 時才找出工具的位置，防止工具儲存位置的更改。

%install
%{__rm} -rf $RPM_BUILD_ROOT
%{__install} -d $RPM_BUILD_ROOT%{appdir}
%{__install} -d $RPM_BUILD_ROOT%{menudir}
%{__install} -d $RPM_BUILD_ROOT%{icondir}
%{__install} -d $RPM_BUILD_ROOT%{_bindir}

%{__cp} -R emesene/* $RPM_BUILD_ROOT%{appdir}
%{__cp} $RPM_BUILD_ROOT%{appdir}/emesene $RPM_BUILD_ROOT%{_bindir}/
%{__cp} emesene/themes/default/trayicon.png $RPM_BUILD_ROOT%{icondir}/emesene.png
desktop-file-install --dir $RPM_BUILD_ROOT%{menudir}/ %{SOURCE1}

%{__chmod} 755 $RPM_BUILD_ROOT%{appdir}/Controller.py

%{__mv} $RPM_BUILD_ROOT%{podir}/ar/LC_MESSAGES/emesen.po $RPM_BUILD_ROOT%{podir}/ar/LC_MESSAGES/emesene.po
%{__mv} $RPM_BUILD_ROOT%{podir}/ar/LC_MESSAGES/emesen.mo $RPM_BUILD_ROOT%{podir}/ar/LC_MESSAGES/emesene.mo


%clean
%{__rm} -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%doc emesene/docs
%doc emesene/COPYING
%dir %{appdir}
%dir %{podir}
%lang(ar) %{podir}/ar
%lang(de) %{podir}/de
%lang(es) %{podir}/es
%lang(fi) %{podir}/fi
%lang(fr) %{podir}/fr
%lang(hu) %{podir}/hu
%lang(it) %{podir}/it
%lang(nl) %{podir}/nl
%lang(pt) %{podir}/pt
%lang(pt_BR) %{podir}/pt_BR
%lang(sv) %{podir}/sv
%lang(tr) %{podir}/tr
%lang(zh_CN) %{podir}/zh_CN
%lang(zh_TW) %{podir}/zh_TW
%{appdir}/[A-Za-oq-z] *
%{appdir}/plugins_base
%{_bindir}/emesene
%{menudir}/emesene.desktop
%{icondir}/emesene.png


%changelog

* Thu Jan 31 2008 Caius Chance <cchance@redhat.com> - 0.99-3.fc9
- Fixed locale 'sv' files appearing twice.

* Tue Jan 29 2008 Caius Chance <cchance@redhat.com> - 0.99-2.fc9
- Refined .spec file regarding 'file' section in spec. (rhbz#238379)

* Mon Jan 14 2008 Caius Chance <cchance@redhat.com> - 0.99-1.fc9
- Sync to upstream perferred version number, refined .spec file. (rhbz#238379)

* Mon Jan 07 2008 Caius Chance <cchance@redhat.com> - 1.0-2.fc9
- Updated .spec file by package reviewer's feedback. (rhbz#238379)

* Fri Dec 21 2007 Caius Chance <cchance@redhat.com> - 1.0-1.fc9
- Updated .spec file by package reviewer's feedback. (rhbz#238379)

* Sat Dec 15 2007 Caius Chance <cchance@redhat.com> - 0.1-2.fc9
- Corrected executable file path parameters.

* Fri Dec 14 2007 Caius Chance <cchance@redhat.com> - 0.1-1.fc9
- Adopted from community as new package.

包裝 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

Comments