0520rpm_and_srpm.htm

鸟哥的linux私房菜

	设定编译参数、实际的编译、最后还要依据个人喜好的方式来安装套件到定位。
	这过程是真的很麻烦的，而且对于不熟整个系统的朋友来说，还真是累人啊！<br><br>

	那有没有想过，如果我的 Linux 系统与厂商的系统一模一样，那么在厂商的系统上面编译出来的执行档，
	自然也就可以在我的系统上面跑棉！也就是说，厂商先在他们的系统上面编译好了我们使用者所需要的套件，
	然后将这个编译好的可执行的套件直接释出给使用者来安装，如此一来，由于我们本来就使用厂商的
	Linux distribution ，所以当然系统是一样的，那么使用厂商提供的编译过的可执行档就没有问题啦！
	说的比较白话一些，那就是利用类似
	Windows 的安装方式，由程式开发者直接在已知的系统上面编译好，再将该程式直接给使用者来安装，如此而已。<br><br>

	那么如果在安装的时候还可以加上一些与这些程式相关的资讯，将他建立成为资料库，
	那不就可以进行安装、反安装、升级与验证等等的相关功能棉(
	类似 Windows 底下的『新增移除程式』 )？！确实如此，在 Linux 
	上面至少就有两种常见的这方面的套件管理员，分别是
	RPM 与 Debian 的 dpkg ，其中又以 RPM 更常见。所以底下我们就来介绍一下 RPM
	这个咚咚棉！<br><br>

	<hr><a NAME="intro_whatisrpm"></a><img src="../images/penguin-s.gif" alt="小标题的图示" height="23" width="16" align="middle" /><span class=text_h2>什么是 RPM 与 SRPM</span>
	<div class=block2>
		RPM 全名是『<span class=text_import2> RedHat Package Manager </span>』简称则为
		RPM 啦！顾名思义，当初这个套件管理的程式是由 Red Hat 这家公司发展出来的，
		但其实在很多的其他套件也有相类似的套件管理程式。不过由于
		RPM 使用上很方便，所以就成了目前最热门的套件管理程式啦！<br><br>

		那么什么是 RPM 呢？说的简单一点， 
		<span class=text_import2>RPM 是以一种资料库记录的方式来将你所需要的套件安装到你的 Linux 
		主机的一套管理程式</span>。他最大的特点就是将您要安装的套件先编译过(
		如果需要的话 )并且打包好了，透过包装好的套件里头预设的资料库记录，
		记录这个套件要安装的时候必须要的相依属性模组(
		就是你的 Linux 主机需要先存在的几个必须的套件 )，当安装在你的 Linux 主机时，
		RPM 会先依照套件里头的纪录资料查询 Linux 主机的相依属性套件是否满足，
		若满足则予以安装，若不满足则不予安装。那么安装的时候就将该套件的资讯整个写入
		RPM 的资料库中，以便未来的查询、验证与反安装！这样一来的优点是∶

		<ol><span class=text_import2>
		<li>由于已经编译完成并且打包完毕，所以安装上很方便( 不需要再重新编译 )；
		<li>由于套件的资讯都已经记录在 Linux 主机的资料库上，很方便查询、升级与反安装；
		</ol></span>

		但是这也造成很大的困扰，由于 RPM 程式是已经包装好的资料，也就是说，
		里面的资料已经都『编译完成』了！所以，
		<span class=text_import2>安装的时候一定需要当初安装时的主机环境才能安装</span>
		，也就是说，当初建立这个套件的安装环境必须也要在你的主机上面出现才行！例如
		rp-pppoe 这个 ADSL 拨接套件，他必须要在 ppp 这个套件存在的环境下才能进行安装！如果你的主机并没有
		ppp 这个套件，那么很抱歉，除非您先安装 ppp 否则 rp-pppoe 就是不让你安装的(
		当然您可以强制安装，但是通常都会有点问题发生就是了！ )。<br><br>

		所以，<span class=text_import2>通常不同的 distribution 所释出的 RPM 档案，并不能用在其他的 
		distributions 里面</span>，举例来说，
		Fedora 释出的 RPM 档案，通常无法直接在 Mandriva 上面进行安装的，更有甚者，
		不同版本之间也无法互通，例如 Fedora Core 4 的 RPM 档案就无法直接套用在 FC3 
		上面！因此，这样可以发现他的缺点是∶

		<ol><span class=text_import2>
		<li>安装的环境必须与打包时的环境需求一致或相当；
		<li>需要满足套件的相依属性需求；
		<li>反安装时需要特别小心，最底层的套件不可先移除，否则可能造成整个系统的问题！
		</ol></span>

		那怎么办？呵呵！还好，还有 SRPM 这个东西！ <span class=text_import2>SRPM 是什么呢？顾名思义，他是
		Source RPM 的意思，也就是这个 RPM 档案里面含有原始码(
		Source Code )哩</span>！特别注意的是，这个 
		<span class=text_import2>SRPM 所提供的套件内容『并没有经过编译』</span>，
		他提供的是原始码喔！<br><br>

		通常 <span class=text_import2>SRPM 的附档名是以 ***.src.rpm 这种格式来命名的</span>
		。不过，既然 SRPM 提供的是原始码，那么为什么我们不使用
		Tarball 直接来安装就好了？！这是因为 SRPM 虽然内容是原始码，
		但是他仍然含有该套件所需要的相依性套件说明、以及所有
		RPM 档案所提供的资料，同时，他与 RPM 不同的是，他也提供了参数设定档( 就是
		configure 与 makefile 啦！ )。所以，如果我们下载的是 SRPM ，那么要安装该套件时，RPM
		套件管理员将会<span class=text_import2>(1)先将该套件以 RPM 管理的方式编译，(2)然后将编译完成的
		RPM 档案安装到 Linux 系统当中</span>。与 RPM 档案相比， SRPM 多了一个重新编译的动作，
		而且 <span class=text_import2>SRPM 编译完成会产生 RPM 档案</span>。<br><br>

		怪了，怎么 SRPM 这么麻烦呐！还要重新编译一次，那么我们直接使用 RPM
		来安装不就好了！？<span class=text_import2>通常一个套件在释出的时候，都会同时释出该套件的
		RPM 与 SRPM 。我们现在知道 RPM 档案必须要在相同的 Linux 环境下才能够安装，而
		SRPM 既然是原始码的格式，自然我们就可以透过修改 SRPM 内的参数设定档，然后重新编译产生能适合我们
		Linux 环境的 RPM 档案，如此一来，不就可以将该套件安装到我们的系统当中，而不必与原作者打包的
		Linux 环境相同了</span>？这就是 SRPM 的用处了！<br><br>
	</div>

	<hr><a NAME="intro_i386586"></a><img src="../images/penguin-s.gif" alt="小标题的图示" height="23" width="16" align="middle" /><span class=text_h2>什么是
	i386, i586, i686, noarch</span>
	<div class=block2>
		好啦！现在我们已经知道 RPM 与 SRPM 的格式了，分别为∶<br>

<table class="term"><tr><td class="term"><pre>
<span class=term_write>xxxxxxxxx.rpm<span>   <span class=term_note>&lt;==RPM 的格式，已经经过编译且包装完成的 rpm 档案；
<span class=term_write>xxxxx.src.rpm<span>   &lt;==SRPM的格式，包含未编译的原始码资讯。</span>
</pre></td></tr></table>

		那么我们怎么知道这个套件的版本、适用的平台、打包的次数呢？呵呵！只要透过档名就可以知道了！例如
		<span class=text_import2>rp-pppoe-3.1-5.i386.rpm</span>
		这的档案的意义为∶<br>

<table class="term"><tr><td class="term"><pre>
<span class=term_write>rp-pppoe -        3.1    -     5        .i386        .rpm</span>
套件名称   套件的版本资讯 释出的次数 适合的硬体平台 附档名
</pre></td></tr></table>

		除了后面适合的硬体平台与附档名外，主要是以『-』来隔开各个部分，
		这样子可以很清楚的发现该套件的名称、版本资讯、打包次数与操作的硬体平台！
		好了，来谈一谈每个不同的地方吧∶<UL>

		<li><span class=text_import1>套件名称</span>∶<br />
			当然就是每一个套件的名称了！上面的范例就是 rp-pppoe 。</li><br>

		<li><span class=text_import1>版本资讯</span>∶<br>
			每一次更新版本就需要有一个版本的资讯，否则如何知道这一版是新是旧？
			这里通常又分为主版本跟次版本，以上面为例，主版本为
			3 ，在主版本的架构下更动部分原始码内容，而释出一个新的版本，就是次版本啦！
			以上面为例，就是 1 棉！</li><br>

		<li><span class=text_import1>释出版本次数</span>∶<br>
			也就是<span class=text_import2>编译的次数</span>啦！那么为何需要重复的编译呢？
			这是由于同一版的套件中，可能由于有某些
			bug 或者是安全上的顾虑，所以必须要重新设定当初打包时候的设定参数，
			设定完成之后重新编译并打包成 RPM 档案！因此就有不同的打包数出现了！(
			<span class=text_vbird> 注∶这个时候原始码其实还是
			3.1 那个版本，只是下达编译时的参数不同而已！ </span>)</li><br>

		<li><span class=text_import1>操作硬体平台</span>∶<br>
			这是个很好玩的地方，由于 RPM 可以适用在不同的操作平台上，
			但是由于不同的平台设定的参数还是有所差异性！并且，我们可以针对比较高阶的
			CPU 来进行最佳化参数的设定，所以就有所谓的 i386, i586, i686 与 noarch 
			等的档案名称出现了！<br><br>

<table width=90% border=1 cellspacing=0 cellpadding=3 bgcolor=lightyellow>
<tr bgcolor=lightblue align=center><td width=80>平台名称</td><td>适合平台说明</td></tr>
<tr><td align=center><span class=text_import2>i386</span></td>
	<td>几乎适用于所有的 x86 平台，不论是旧的 pentum 或者是新的 pentum-IV 与 
	K7 系列的 CPU等等，都可以正常的工作！那个 i 指的是 Intel 相容的 CPU 的意思，至于 386 
	不用说，就是 CPU 的等级啦！</td></tr>
<tr><td align=center><span class=text_import2>i586</span></td>
	<td>就是 586 等级的电脑，那是哪些呢？包括 pentum 第一代 MMX CPU， AMD 的 K5, K6 系列 CPU 
	( socket 7 插脚 ) 等等的 CPU 都算是这个等级；</td></tr>
<tr><td align=center><span class=text_import2>i686</span></td>
	<td>在 pentun II 以后的 Intel 系列 CPU ，及 K7 以后等级的 CPU 都属于这个 686 等级！</td></tr>
<tr><td align=center><span class=text_import2>noarch</span></td>
	<td>就是没有任何硬体等级上的限制。一般来说，这种类型的 RPM 档案，里面应该没有 binary file 存在。</td></tr>
</table><br>

			需要额外说明的是，<span class=text_import2> i386 的档案可以在任何的机器上面安装</span>，
			不论是 586 或者是 686 的机器，但是 <span class=text_import2>i686 则不一定可以使用于
			386 或者是 586 的硬体上面，这是因为 i686 的 RPM 档案在编译的时候，主要是针对
			686 硬体等级的 CPU 来进行最佳化编译，而 386/586 等级的硬体可能由于无法支援该最佳化参数，
			所以无法使用呢</span>！另外，在
			686 的机器上使用 i686 的档案会比使用 i386 的档案，效能可能比较好一些！无论如何，使用
			i386 应该就是比较没有问题的啦！另外，由于不同的 distirbution 会有不同的环境与函式库，所以在
			i386 之后也有可能会额外再加上该套件的简写！</ul>
	</div>

	<hr><a NAME="intro_advance"></a><img src="../images/penguin-s.gif" alt="小标题的图示" height="23" width="16" align="middle" /><span class=text_h2>RPM 的优点</span>
	<div class=block2>
		RPM 有以下的优点∶<ul><span class=text_import2>
		<li>RPM 档案本身为已经编译过的 binary 档案，可以让 client
			端的使用者免除重新编译的困扰；
		<li>RPM 档案在被安装之前，RPM 会先检查系统的硬碟容量、作业系统版本等，可避免档案被安装错误；
		<li>RPM 档案本身提供套件版本资讯、相依属性套件名称、套件用途说明、套件所含档案等资讯，便于了解套件；
		<li>RPM 管理的方式使用资料库记录 RPM 档案的相关参数，便于升级、移除、查询与验证。
		</ul></span>

		为什么 RPM 在使用上很方便呢？我们前面提过， RPM 这个套件管理员所处理的套件，是由套件提供者在特定的
		Linux 作业平台上面将该套件编译完成，并且打包好，那使用者只要拿到这个打包好的套件，
		然后将里头的档案放置到应该要摆放的目录，不就完成安装棉？！对啦！就是这样！
		但是有没有想过，我们在前一章<a href="0520source_code_and_tarball.php">原始码与 Tarball</a> 
		里面提过的，有些套件是有相关性的，例如要安装网路卡驱动程式，就得要有
		kernel source 与 gcc 及 make 等套件。那么我们的 RPM 套件是否一定可以安装完成呢？！
		如果该套件安装之后，却找不到他相关的前驱套件，那不是挺麻烦的吗？因为安装好的套件也无法使用啊！<br><br>

		为了解决这种具有相关性套件之间的问题，就是所谓的套件相依属性，RPM 
		就在提供套件打包的档案时，同时加入一些讯息登录的功能，这些讯息包括套件的版本、
		打包套件者、相依属性的套件、套件的功能说明、该套件的所有档案与目录纪录、等等，然后在
		Linux 系统上面亦建立一个 RPM 套件资料库( database )，如此一来，当您要安装某个以
		RPM 型态提供的套件时，在安装的过程中， RPM 会去检验一下资料库里面是否已经存在相关的套件了，
		如果资料库显示不存在，那么这个 RPM 档案『预设』就不能安装( 
		<span class=text_vbird>会显示一些错误讯息</span>
		)。呵呵！没有错，这个就是 RPM 类型的档案最为人所诟病的『
		<span class=text_import1>套件的属性相依</span>』问题啦！<br><br>
	</div>

	<hr><a NAME="intro_solution"></a><img src="../images/penguin-s.gif" alt="小标题的图示" height="23" width="16" align="middle" /><span class=text_h2>RPM
	属性相依的克服方式</span>
	<div class=block2>
		虽然 RPM 有套件属性相依的问题，但是 RPM 的优点实在是比缺点要好的多，所以很多使用者还是偏好使用
		RPM 来管理自己的套件，在这样的情况下，如何解决 RPM 的属性相依问题呢？最简单的方式就是在安装
		RPM 档案的时候，发生套件相依的问题时，手动去下载前驱套件，先安装好这些套件，
		然后再安装最终想要安装的套件即可。但是，如此一来很花费使用者的精神与时间，挺麻烦的啦！
		有没有比较快速的方法呢？<br><br>

		呵呵！有的，由于 RPM 类型的档案里面含有属性相依的讯息存在，如果我们可以透过分析这些讯息，
		再让程式自行去寻找未安装的前驱套件，并事先加以安装，如此一来不就解决了属性相依的困扰了吗？！
		没错！是这样！这就是目前所谓的 <a href="../linux_server/0450apt.php">urpmi/apt/yum</a>
		等服务的由来啦！这些服务都是透过分析 RPM 档案的相依资讯，然后自行取得相依属性套件，
		自行完成安装的动作，呵呵！相当的方便呢！这些资讯我们会在
		<a href="../linux_server/">伺服器架设篇</a>
		里面进行介绍，在这个章节当中，我们主要还是以单纯的 RPM 为主喔！
	</div>