我们知道ubuntu有别于gentoo之一的特点就是，gentoo是基于源码包安装的系统，而ubuntu是基于二进制的。我们执行一个apt-get install foo安装包命令时，apt从对应的apt source源地址下载一个二进制包-以.deb为后缀名的文件到/var/cache/apt/archives下，再用dpkg工具安装它们。这些.deb文件都是包的维护者在某台build machine上build之后放上去的，而与foo.deb对应的源码包，一般都是指三个文件的一个集合：foo.orig.gz, foo.dsc, foo.diff.gz. foo.orig.gz是该软件的原始源码，通常取自于git，svn或sourceforge，可以把它看作是中立的，和Linux发行版无关的源码。foo.diff.gz包含了将一份原始源码加工、改造为debian系安装包的非功能性的补丁文件，或许同时也包括一些功能性的修补源码bug的补丁。foo.dsc是一个包描述文件，它是一些ubuntu上的源码包处理工具如dpkg-source的输入。foo.diff.gz和foo.dsc扮演meta package的角色。一般来说，一个或者多个二进制包都对应一份源码包（因为多个二进制包可能由同一个源码产生），source.list的deb-src标鉴说明了可以通过apt-get从哪些网络地址获取源码包.
既然已经有了二进制包，为什么有时候还要从源码包来生成软件？因为二进制包毕竟是在别人的build machine上生成的，自然产生的二进制依赖也是基于维护人的环境。假如你想使用一个软件的更高版本，可能是因为高版本修订了当前使用版本的某个bug，或者想看看新的更省电的feature，当你把该软件高版本的apt source源添加到了source.list，然后使用apt-get update; apt-get install foo=high_version时，你发现apt-get抱怨很多运行时依赖得不到满足；而不得不把Ubuntu的整个release version升级，其实，你想做的只是升级这个软件包而已，发行版其他的部分仍然想保留已经使用了很久的版本，那这时从源码包构建软件就是必须的了。这里我个人就经历过这样的例子，在12.04LTS系统里，cairo-dock这个软件是有bug的，如果要升级，就得升级发行版，因为新的cairo-dock依赖新的xserver stack，而新的xserver stack牵涉的东西太多，那么就得升级发行版，当采用官方的源把xserver stack升级到最新版时，发现它已经帮你默认采用xmir了…天，我只是想用一个新版本的cairo-dock而已，并不想升级我的内核，libc，更不想用什么mir。这时我只有从网上下载更新版本的cairo-dock的源码包来构建，当然在构建过程中，必然会发先cairo-dock确实有些依赖不被当前的xserver stack所满足（比如用了更新的api或者数据结构都变了），那这时你就只有再把满足依赖的xserver stack包下下来编译（是一个递归收敛的过程），有可能要调整默认的编译参数（比如build最新的xserver core时把xmir disable掉）这个过程当然不容易，但做多了有经验后再碰到类似问题就相对容易多了。你也许会说从源码构建很简单啊，不就是git clone源码仓库然后./configure; make; make install吗？但这种构建方式只会产生二进制文件，不会产生二进制.deb包，操作系统的包管理器只有通过.deb包安装，它才知道用户安装过这个程序，有哪些二进制文件属于这个”包”等，这样不管以后的升级，卸载，替换等都有踪可循，如果直接从源码构建，那你以后要卸载它怎么办？你还记得它的源码放在哪里吗？它是用make uninstall卸载的还是其他什么命令？一些目录甚至可能是写死的，并且，如果你的软件包含一些库会被其他软件依赖，那么包管理器也可以通过包数据库为这些依赖提供线索，如果直接使用源码构建软件，那相当于你机器上的软件依赖链条出现了断裂，这会影响后续软件的安装卸载管理。
原文地址：http://blog.csdn.net/redredbird/article/details/46513747
