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