原提问见：
http://bbs.chinaunix.net/forum/viewtopic.php?t=608443
题目为：请问RPM包与tar到底有何区别？？
------------------------------------------
要了解tar与rmp的差别，不妨先从软件的产生开始谈吧。
简单来说，现今的电脑，之所以能运作，是因为它会处理的0跟1，但问题却也是只能处理0跟1。
因此，要让电脑能执行的软体程式，必需以0跟1的二进位（二进制）格式出现，我们称之为---执行码（可执行文件）。
而且，不同的CPU所执行的格式都不尽相同，我们称之为硬件平台（平台）。
以个人电脑来说，最常见的硬件平台多是英特尔公司设计（或兼容）的CPU，常称为I386或X86。
然而，二进位格式却造成程式设计师撰写程式的难度太高了！ （呵，别怀疑，早期的确如此〜〜）
聪明的人们，于是选用了别种较为易懂的方式来转写，也就是我们常说的“程式语言”了。
我们称这些写用程式语言撰写的代码为---源代码（源代码）。程式语言很多，在UNIX / Linux的世界里，Ç语言是最传统也最常用的程式语言。
在这基础上，我们需知道如下事实：
1）我们可用的程式语言很多种。
2）可供执行的硬件平台也很多种。
3）用程式语言写好的源代码并不会自动变成二进位格式。
这就是“编译器（编译器）”上场的时候了。换句话来说：
---写好的源代码必须针对不同的硬件平台进行编译才能能产生执行码。
不同语言的源代码及不同硬件平台均需要不同的编译器来执行这项工作。
要是你用Ç来写源代码的话，那最常见的编译器就是Ç编译器，简称为CC。
然而CC也有很多不同的版本，功能效能及作业平台或有所不同。
Linux的最常见的就是GNU的C编译器，简称为GCC。
当你写好c代码，同时装好了GCC，那你就可执行的gcc编译出执行码。
然后，再将编好的执行码复制到相关路径，人们便可在这台机器上执行该程式了。
我这里暂不介绍如何写Ç代码，也不介绍怎么跑的gcc，有待大家自己学习。
事实上，越复杂的程式，代码越长，也越难设计与为护，而GCC可选用的参数也越多。
我这里也暂时不介绍函式库（库）的概念了，但其实这方面还可大书特书的。
我非常建议读者搞懂函式库的概念，尤其是静态（静态）与动态（动态）函式调用方式的差别。
因为这会扯上执行环境的依赖性及程式的移植性，也就是所谓的---软件依存关系（依赖）。
嗯，还是先请大家自己琢磨吧，要是日后有机会的话，再回来跟大家介绍好了。
到此为止，相信大家已经知道软件是怎么蹦出来的了！
然而，如下问题，请大家不妨老实作答：
1）你会写源代码吗？
2）你会得执行GCC及相关参数吗？
（呵...坦白讲，我就不是很懂了！）
而且，就算你懂了，那：
3）你愿意每次安装软件都敲上百行的gcc的命令吗？
（呵...同样的，我也不愿意！）
将心比心，那些普通电脑使用者呢？他们又作何感想呢？
难道拥抱软件非要如此折腾不可？
这里，请你先记着这句话：
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
前面提及的，从二进位撰写改为从源代码撰写，就是一个很了不起的进步。更别提古老的“打孔卡”年代了！
然而，这进步是不够的...人们并不满足啊〜〜〜
于是，就有了做这个程式出现了。
简单而言，就是读入一份预先编写好的Makefile文件，然后自动的帮我们完成所有的编译工作。
具体的Makefile文件格式，我这里也暂时莫属了过，还是留给大家自行学习。 （我这里只想讲概念）
能理解的Makefile带来的进步很重要，因为后面提到的转规格也是源于相同的理念。
从此，我们只需跑几个简单的指令，就能代替过往上百成千行的gcc的命令了！
多么美妙的事情！
好吧，不得不承认的Makefile曾经为人们带来过一段时间的满意。
这是很好的，但还不够好！
还有啥不满足呢？
随着电脑的普及，软件的散播速度也大大的提高了。
且，面临的各种不同的执行环境差异也越来越广。
人们慢慢发现：单一的Makefile文件没法满足所有环境的需求！
怎么办？
呵....回到前面的老话：
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
于是，聪明的人们，开始撰写一些环境侦查工具，大多是一些脚本语言（外壳，perl的等等），
让使用者可以先执行之，然后按不同的侦查结果自动修改Makefile文件。
同时，用心的作者，还允许使用者透过各种参数，来指定特殊的需求。
是啊......完美？
Nooooooooooooooot！
又怎了？
唉呀，亲爱的朋友啊，要是我不讲，你怎知道原来还可以这样玩呢？
更何况那些快快乐乐只想跑应用的普通用户呢？就算我这样讲，对他们来说，还是一头雾水啊〜〜〜
不用担心！
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
于是，作者一不做二不休，干脆将所有步骤及可能的环境需求与操作，写成文档，让使用者慢慢读就是了。
这，就是README，INSTALL这类文档存在的意意了！
呵...到这里，你是否豁然开朗了吗？原来，我们之前常看到人们装软件都是如此跑的：
1）更少README INSTALL
2）在。/ configure
3）
4）安装
只要你能理解前面所讲的，那，你就能了解为何都是这几个步骤了... ^ _ ^
这就是人们常说的“源代码安装”方式了，或称为压缩包。
（嗯，压缩包其实还要扯上焦油与GZIP / gunzip解等程式，我这里也暂时不谈了。）
然而，问题真的解决了吗？
你以为真的从此就天下太平了吗？
若你认为满足的话，那我再来问你几个问题：
1）你知道系统一共装了哪些软件吗？
2）它们是谁提供的？版本为何？
3）你知道刚刚装的软件装哪去了？
4）你知道自从安装后，有哪些文件被修改过？
5）这个软件要依存哪些其他软件吗？
6）又有哪些软件依存你这个软件呢？
7）你可以放心的移除它或升级它吗？
8）你知道其他伙伴又装了哪些改了哪些吗？
9）你知道这每一台机器的软件状况吗？
9）若你要将职务交接给别人，你能交代清楚吗？
10）要是你从别人接管过来呢？
等等又等等....
这些一直以来都是软件管理上必答的问题。然而，你的答案又有几多呢？
别跟我说，你可以耍赖不答哦。要是你自己的系统，随便你怎搞都行。
但，要是你是每月都领别人薪水的话，这些基本问题答不出来，你还好意思拿？你还有脸说要加薪？
嗯？？
你在冒冷汗了吗？朋友？
呵...不用内疚啦，不只是你，很多人都碰到同样的问题啊...
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
那，请问，接下来，换收成是你的话，怎么解决上述那些问题？
1）用脑记？
2）用笔写？
3）请秘书？
4）置之不理？
呵...朋友，别忘了你是个聪明的IT专业人员哦〜〜〜
5）写成电子文档吗？
够了吗？当然不够！
6）做成数据库（数据库）？
yeeeeeaaaaahhhhhhhhhhhh！宾果！你中奖了！
你从事IT这么久了，难道没想到：凡是要备案查询的东西就交给数据库吧！
是的！我们也可用数据库来追踪及管理我们的软件资讯啊，不是吗？
事实的确就是如此！
不过，你会写数据库吗？就算会写，能否用来管我们的软件吗？
（老实又坦白的说：老子就不会！）
怎样？难道不可用别人的吗？
呵....是的：用别人的劳动成果---这跟你不用自己写源代码的道理是一样的！
那，用谁的呢？
其实答案已经呼之欲出了--- Redhat软件包管理（RPM）就是其中佼佼者。
这个词中的包装指的就是我们装在电脑上的软件了。
（包装的企业管理跟软件管理其实是有差别，我们这里谈的是包）。
RPM有啥能耐呢？
说穿了，就是一个数据库而已。
有了它，前面问到的关于软件管理的问题全部商情都可以轻松就回答出来了。
呵...关于转指令的运用，我这里同样略过，只讲原理，好吗？
好呀！
那么，转DB又怎么冒出来的呢？
嗯.....这个就要扯上转的规格了。
还记的前面提到的Makefile文件吗？
若你记得的Makefile可以自动跑的gcc的话，
那么一个简单的转规格就是帮你自动跑配置跟使那些指令！
然后，再额外增加了数据库的资料项目。
当然，规范的文件可以写的很复杂，不过，你应知道我讲啥了吧？
---关于规范的撰写，我这里同样略过....
哈〜〜〜被我打败了吗？呵〜〜〜〜〜〜慢慢来，只讲原理，好吗？
当你有了一个压缩包之后，你就可另行撰写转的规格，
然后用rpmbuild的指令，完成规范所定议的每一道指令。
（其实跟你自己跑做差不多，只是更为自动化而已...）
最终，可以生成二进制RPM格式的文件。
然后，再用RPM命令按照规范的定议将所有文件安装好，并修改数据库，完成一切。
这样，你之前用tar包装的东西不会少掉，但是数据库就存有关于软件的所有资讯了！
岂不美哉？ ^ _ ^
持有...
是不是不够好？亲爱的？
我们必须承认：人心是不足的！
是啊，有了RPM不见的就能解决所有软件问体。
装过RPM的朋友，一定都碰过依赖的问题吧？
唉，这部份，我真不想讲了，现等你对库有了概念，再回来探讨好了。
只能说，RPM只是好心，但不见的有好报啦...
这心境，跟我们常在论坛回答问题还遭白眼的情形差不多的....唉...无奈... > _ <
唉...那就不说了吧。
除了依赖之外，RPM还有哪些不足呢？
嗯。首先，人们拿到的大都是二进制RPM，也就是规格已定死，编译已完成的转速。
就算下载回来，也无从改起。
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
于是，有了源RPM的存在。
说穿了，源RPM只不过是包了压缩包跟转规格这两样东西而已。
只要将src.rpm的装好，然后你就可修改规格，也可打开压缩包修改里面的代码及Makefile文件。
修改好之后，再次将之编译成为二进制RPM就行了。
这给了人们很大的弹性，又不失RPM分贝的便利。
假如你找不到满意的二进制RPM的话，那就找源转吧。你会喜欢它的！
而且，就算没有源RPM，现在很多压缩包里面，作者们也都主动提供了规范。
如此，人们就可以随时地自己建出合用的二进制RPM了。
嗯。 RPM就是好啊！
但是，每个二进制RPM都是零散的，我们常要为了装一个软件，而顺藤摸瓜的抓了一堆RPM回来。
（这里我一定要提醒版本的问题，因为这会扯上软件环境，也就是前面提到的恼人的依赖问题。
然而，平心而论，凡是软件都会碰到的依赖，只是RPM把关工作做得严谨而已。）
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
是的，于是有了包服务器的概念。
也就是，从此，我们的软件不再需要抓到自己的机器去了。
这一切都拜网络所赐：我们将所有软件都集中放到服务器去，分们别类进行管理。
我们只需在客户端装个弗朗端工具，将一个或多个服务器的地址设上去。
从此，每一台机器都有了源源不绝的转速或src.rpm的。
现在较新发行的Linux的版本，都全部采用这一方式来管理软件了。
当然，有些版本不见得是用RPM啦（如debian的geento）...不过原理却是一样的。
比方你用最新版的红帽/ Fedora的，
只要跑yum的更新就会将当前的软件全更新了yum安装就可安装指定的软件。
若还需要其他依存软件，也自动一一下载并完成安装。
甚至还可以将整个系统进行升级！
呵...是的。目前来说，较之以前的压缩包年代，软件的管理工作已经相当便捷而成熟了。
希望本文，能助大家对软件管理（包管理）有一简单的了解。
若你不想深究原理的话，那你也不需苦恼，只须乖乖记着如下的忠告就行：
1）能用百胜，容易的urpmi，YAST等先进的软件管理工具，就尽量用吧。
转2）能用就尽量用吧，但要注意版本要一至。
3）要是不行，还有源转可用。
4）真的没法子，那才用压缩包。
5）当然，你自己能写代码的话，那就更不用愁了！
再一次：
---软件之所以进步，就是因为人们会随时随地将存在的问题解决掉！
我相信，软件管理的进步，还是会持续下去的，日后会面临什么问题？或得到什么解决？现在不需过份担心。
尽管抱着积极乐观的态度去迎接将来就是了！
祝大家：
中秋快乐！
网球运动员
2005年9月10日于台南