安装包特性：
1、开始拷贝文件之前的操作都具有可逆性；
2、具有“默认安装”与“自定义安装”两种安装方式可选；
3、自动生成卸载脚本；
4、安装时能自动建立桌面快捷方式，卸载时能自动清除配置文件、游戏存档等软件残留文件。
以下操作以在红旗桌面版4.1下制作EVA-0.4.0的安装包为例，需要读者掌握编写SPEC文件、建立与编辑桌面配置文件*.desktop、shell脚本编程、Xdialog方面的相关知识。
制作步骤：
1、以root身份登录系统，或者在普通用户下以root权限进行操作。
2、获取软件编译安装后的目录结构
将软件的源码压缩包放到/usr/src/redflag/SOURCES目录下，在/usr/src/redflag/SPECS目录下建立一个SPEC文件，例如eva.spec。内容为：
引用:
%define prefix /usr
%define appsdir /usr/share/applnk/App/Internet
Name: eva
Summary: KDE环境下的QQ客户端软件
Version: 0.4.0
Release: rfdt4.1
Source0: %{name}-%{version}.tar.bz2
Group: Applications/Internet
BuildRoot: /tmp/build-root-%{name}
License: GPL
Url: http://www.linuxfans.org/downloads/
Packager: your name <your email>
%description
Eva 是在KDE桌面下，基于Qt库开发的软件， ………
%prep
rm -rf %{buildroot}
%setup -n eva
%build
./configure --prefix=%{prefix}
make
%install
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{appsdir}
make DESTDIR=$RPM_BUILD_ROOT install
cd $RPM_BUILD_ROOT
find . -type d | sed '1,2d;s,^\.,\%attr(-\,root\,root) \%dir ,' > $RPM_BUILD_DIR/file.list.%{name}
find . -type f | sed 's,^\.,\%attr(-\,root\,root) ,' >> $RPM_BUILD_DIR/file.list.%{name}
find . -type l | sed 's,^\.,\%attr(-\,root\,root) ,' >> $RPM_BUILD_DIR/file.list.%{name}
%clean
%files -f ../file.list.%{name}
%defattr(-,root,root)
%doc AUTHORS ChangeLog COPYING NEWS README README.zh
%changelog
在终端进入/usr/src/redflag/SPECS目录，执行：
rpmbuild -bb eva.spec
完成后，/tmp/build-root-eva目录下就是EVA-0.4.0编译安装后的目录结构，/usr/src/redflag/BUILD目录下的file.list.eva文件是EVA-0.4.0编译安装后的文件列表。
3、配齐文件
建立/tmp/evainstaller目录，将installer-files.tar.bz]2解压后得到的installer-files文件夹里的所有文件都放到这个目录里。
将/tmp下的build-root-eva目录拷贝到/tmp/evainstaller目录，改名为eva-0.4.0，在/tmp/evainstaller/eva-0.4.0/usr/share/applnk/App/Internet下建立 EVA 的开始菜单（K菜单）项目，记得包括eva-uninstall.desktop（执行的命令为“/usr/share/doc/eva-0.4.0/uninstall.bin”）。
为“软件名-版本号-rfdt4.1-installer”和“软件名-版本号-rfdt4.1-setup”这两个文件改名，例如eva-0.4.0-rfdt4.1-installer和eva-0.4.0-rfdt4.1-setup，并建议一个软件的桌面配置文件（建立桌面快捷方式的时候使用），例如eva.desktop。
4、修改eva-0.4.0-rfdt4.1-installer和eva-0.4.0-rfdt4.1-setup这两个文件
其中eva-0.4.0-rfdt4.1-installer需要修改的地方只有“name=”和“ver=”这两个地方。
而eva-0.4.0-rfdt4.1-setup需要修改的地方比较多，除了软件名和版本号需要定义外，“选择安装类型的模块”和“选择安装类型”需要修改文字说明；“默认安装的模块”和“自定义安装的模块”需要参照file.list.eva文件的内容来修改拷贝时的操作；“生成卸载脚本的模块”需要修改删除的文件和目录；“安装完毕给予提示的模块”需要修改文字说明。
5、生成安装包
至此，相关文件已经准备完毕了，最好检查一下，看看/tmp/evainstaller目录下的文件是否是这些：
custom_install.xpm eva-0.4.0-rfdt4.1-setup uninstall_complete.xpm warning.xpm
default_install.xpm eva.desktop uninstall.xpm
eva-0.4.0 install_type.xpm Xdialog
eva-0.4.0-rfdt4.1-installer the_end.xpm Xdialog.mo
确认文件齐全后，将其压缩，在终端进入/tmp/evainstaller目录，执行：
tar jcvf eva.tar.bz2 custom_install.xpm default_install.xpm eva-0.4.0 eva-0.4.0-rfdt4.1-setup eva.desktop install_type.xpm the_end.xpm uninstall_complete.xpm uninstall.xpm warning.xpm Xdialog Xdialog.mo
合成安装包：
cat eva-0.4.0-rfdt4.1-installer eva.tar.bz2 >eva-0.4.0-rfdt4.1-installer.bin
chmod +x eva-0.4.0-rfdt4.1-installer.bin
现在双击eva-0.4.0-rfdt4.1-installer.bin就可以开始安装了。 tanhitzq, 你理解错了，我不是说本身bin占用空间大，而是如果安装多个bin，又都安装在自己的目录，像win一样，会占用空间大，比如两个包都有ld.so，如果都安装在/usr/lib，那这两个ld.so必须没有冲突才行，如果有冲突，就会导致其中一个软件不能用，这也是rpm管理的好处。如果为了避免冲突，那势必要安装在各自的目录，一个两个不要紧，多了也是很占用空间的。 并不是所有的软件都是make编译的
另外make是基于自己系统定制的，不同系统make出来的文件需要的依赖关系也不同，产生的文件也有可能不同，所以不同版本的rpm包装在别的系统上未必能够运行。正如se兄所说，如果每个安装包都把需要的binaries单独放在自己的目录下，那么占用太多空间了 可惜现在很多打包的人，只是为主程序打包，并没有为依赖文件打包。
事实上ld.so冲突这个问题，rpm也是有的。
毕竟打包的人不是同一个人，在缺包的时候，每个人都有不完全相同的解决方法。－－最终同样可能出现ld.so冲突的。 我个人觉得有必要把系统类包和软件包分开，象红旗的软件包管理器就很科学，但红旗应该把这个软件管理器再严格一些，禁止非更新同名软件包时软件对系统默认类库的替换。
很多的RPM包把软件装到/usr，和系统服务和类库堆放在了一起，很少有rpm软件包把软件装在/usr/local或/opt，这也是个通病，rpm包管理机制并没有错，错的是打包的人。 可惜现在很多打包的人，只是为主程序打包，并没有为依赖文件打包。
事实上ld.so冲突这个问题，rpm也是有的。
毕竟打包的人不是同一个人，在缺包的时候，每个人都有不完全相同的解决方法。－－最终同样可能出现ld.so冲突的。
呵呵，我对这个说法保留意见。
在起码在这个社区，包括我在内。很多兄弟在打包的时候都说明、并且提供了依赖包 可惜现在很多打包的人，只是为主程序打包，并没有为依赖文件打包。
我要是做一个 bmp 的包，那这个包里还要放上 glib、xorg、gtk2、glibc……………………
这个包怎么也得有个几十 M 了…………………… 软件的依赖的根本原因并不是打包方式
而是软件开发环境和用户安装环境的差异
Linux的自由软件的性质使得这种差异相对
于windows存在得更广泛。一方面，不同的
发行版，包含的包的种类不同。有时候同
一个软件，拆成的包不一样。还有很多时候
同样一个名字的包，其编译的环境也不一样，
生成的二进制包也是不通用的。另一方面
同一个发行版本，不同用户选择安装的包
也不尽相同。
如果一个用户，不用kde,也没装qt，而开发者
的环境是kde环境，他的软件运行需要kde和qt
那是否打包的人，就要把kde和qt也打包进去。
windows是由一家公司包办的商业系统，安装
完后，每台电脑得到的环境的相似程度远高
于linux。这样打包的人就有了一个相对稳定
的基础。但是并不是windows就不存在依赖。
比如对高版本ie,mediaplayer,directx的依赖。
对开发环境的依赖，如对vb运行库，对dotnet
框架的依赖。对第三方软件的依赖，如对java
虚拟机，flash插件等的依赖。
从某种意义上说，编译安装的方式是降低了软件
的一种相互间的依赖。比如有一个二进制包，很难
在不同版本的内核上运行，那就是说，他依赖于特
定版本的内核。但他的原码包甚至可以在各种unix
like的系统中编译成功，也就是说这种安装方式
不依赖具体的内核。
当然，我并不反对，.bin的发行方式，因为他可以
提供更出色的人机对话环境，可以采用更丰富多彩
的方式进行人机对话。可以有按钮，复选筐，列表
等等，甚至可以有动画，有声音。 同意 lanzinc 同学的观点。我不得不再次强调，不同的发行版其实是不同的操作系统，要认识到这一点，绝不是一朝一夕能作到的。因为这些发行版都叫 GNU/Linux，实在是具有太大的迷惑性。由于开发者出发点不同，也由于用户自己定制的不同，正是自由一手造就了这种不兼容、不通用的苦果。
我要提醒的是，并没有哪种打包方法是绝对优秀的。他们各有不同的使用场合。你的 bin 包引以为傲的交互性，对于系统级的包而言，恰恰是致命的缺陷，系统包在安装的时候，是绝对不允许有任何交互的，甚至不能指望内嵌脚本能够正确执行！一张系统盘有数百个软件包，一个一个地交互安装，那简直尤如到 18 层地狱走上一遭。不知道你注意没有，就连 windows 安装过程中涉及的那数百个包也都是无交互安装的！ 安装过程中的包，绝对是rpm包方便，并且发行方出的都最好是rpm包，因为发行方不可能连依赖都不解决就放出来的。
我说的是爱好者说打的包。
RPM Great
RPM 是我所了解的最完善的Package Management. 注意，我以下观点所提的bin包并非就是现在网上我们所见到的bin包，它可以是我们社区发起新兴的新格式，或许可以起名叫app或use包。:oops:合理的bin包，比如安装在/opt或/usr/local还是受欢迎的，希望bin包能加以完善，使安装位置透明并且能够自定义安装位置，对有覆盖文件现象进行警告并禁止，也就是更智能化。希望有傻瓜化制做bin包的软件被开发出来。
我的意思是说智能化、无包依赖性（自然还是对系统环境有依赖）的bin包会成为rpm包体系的补充，但bin包在rpm系统包体系的基础上，需要有除rpm包管理器外的bin包管理器，这种管理器必需能监控bin包的合法性和安全性，提供必要的分析、安装建议、卸载的能力。
如果Linux桌面想类似于win一样地易用，就必需把系统软件和用户软件分离开，用不同的包管理器进行不同级别的管理(系统需求>软件需求)，不允许用户软件对系统文件进行替换（直接只允许往/opt或家目录里装就是了）。
总之，bin包还是rpm包并没有本质区别，但可以把bin包做成无依赖性的用户软件包来补充严格自身依赖检察的RPM包群，也就是记两本账，谁也不欠谁，必要时沟通商量并解决。 其实有一个软件，具体名称忘记了，不过是商业的，就是做楼上说的这个事情的，但是实际上不可能都达到无依赖的，只能是个别的软件这么做。
就必需把系统软件和用户软件分离开
要做到这点恐怕就有困难。具体应该是什么标准呢？
还有就是这样做了，每个用户各自的系统的"系统软件"所包含的东西也不相同。
除非有个“标准平台”，并且大家都遵守。
但这样linux也就失去了他原本自由的天性。
另外大家的要求不一样，需求有诧异，对系统的内容也就有差异，在多元的需求
面前，标准平台，能否生存下去也是个问题 标准平台是不可能的啦，但跨平台安装和新的无依赖格式安装包的推广还是可能的。