前言
无论何时，只要谈起LINUX，就不可避免的谈到UNIX, 谈到发行版，就不得不谈到软件包管理，顺着软件包管理技术的变革趋势，顺便罗列一段软件世界的部分编年史：
unix： 1969年，美国AT&T公司的贝尔实验室
C 语言： 1972年，美国贝尔实验室的 D.M.Ritchie
make： 1977年，贝尔实验室里,斯图亚特·费尔德曼
gnu Autotools：1983年，源自于理查德·斯托曼提出的GNU计划
linux： 1991年，林纳斯·托瓦兹
dpkggapt: 1993年，debian发行版社区开发者伊恩·默多克
rpmgyum: 1997年, originally Red Hat Package Manager
snappy： 2014年, ubuntu 母公司Canonical开发
源码管理阶段
话说在UNIX的上古时代，一群有着开拓精神的开发者，在那个蛮荒时代开垦软件世界的荒地，就像远古的骑士出征，连武器都需要自己准备一样。那个时代还是汇编语言的天下，尽管汇编语言得可读性比起机器码（machine code)有了长足的改进，但是汇编语言本质上还是符号化的机器语言，不同硬件就需要使用不同的汇编语言。先驱们依旧不辞辛苦地上开垦，这种局面一直持续到到C语言的诞生。此后UNIX开创性使用C语言完成重写，正是C语言有着良好可移植性，UNIX获得空前的成功，UNIX版本曾一度多达百余个版本，软件开发也迎来了一个黄金时代, 尽管make工具解决代码编译依赖等工程问题，然而软件的分发依然停留在源码阶段，压缩打包，上传到ftp，下载，解压，然后就是所熟知的 make && make install。
那个时代离我太遥远，我翻阅我所能查看的资料，我一直认为源码分发的时代持续了很久，人们通过调整编译选项，最大程度地编译安装软件，榨取那最后一点可怜的性能提升，但是没人喜欢机械的下载，编译，安装，于是那个时代诞生了BSD系列操作系统（比如 FreeBSD，NetBSD，和 OpenBSD）家族的包管理系统: Ports collections （又称 ports trees 或直接简称 ports) ，通过提供的 makefile 和 patches，以作为一种简单的安装以及创建二进制包，可以轻松地对软件包进行删除、增添或进行其他操作。除了BSD，之后一些Linux发行版有类似的包管理系统，包括 Gentoo的 Portage，Archlinux 的 Arch编译系统(ABS) ，CRUX 的以及 Void Linux 的 Ports。直到现在这些发行版依然存在，依然拥有着于高度的可定制型，以及比起拥有通用二进制包得发行版有着更好的性能，也许有些人不喜欢这种基于源码管理的方式，但是，就像世界任何事物存在的理由一样，存在即有价值！
二进制包与仓库
20世纪90年代初,GNU计划完成除内核外的大部分工作，林纳斯·托瓦兹在1991年10月5日首次发布LINUX内核。但是真正linux仅仅是内核，一个单独linux内核是无法工作，很多组织或社区，将Linux 内核，来自GNU的工具和库，和附加的软件、文档，甚至还有一个窗口系统，窗口管理器，和一个桌面环境结合来自GNU的工具和库，和附加的软件、文档，窗口管理器，和一个桌面环境等组件，集成在一起，构建一个套件，称作发行版，因为绝大部分工具和软件来自由GNU项目，因此也合称GNUglinux. 原则上只要你足够熟悉编译工具的使用，你完全可以通过编译源码得方式安装升级这些组件，但是人是喜欢偷懒的，没人喜欢机械重复的劳动, 使用源码编译方式管理软件是一种耗时耗力的办法，于是那些不满于现状，并且喜欢偷懒的家伙们，开创了通用二进制包管理方式的发型版本，比如，于tgz压缩包的老牌Slackware发行版，基于Dpkg 的(Debian系)，基于RPM 的(Red Hat系), 尽管像 BSD家族(FreeBSD，NetBSD，和 OpenBSD), Gentoo 这类以发行版本依然可以使用二进制包，但那不是他们的初衷。
包管理系统的区别
所有软件包管理系统都能很好完成安装、升级、移除等功能，在这方面除了命令，参数不同之外，其他方面没有特别得差异，总结一句解压缩和释放软件包，将软件包内文件放置到对应的位置，如果软包内包含预配置脚本，根据安装前，安装后，卸载前，卸载后的条件，运行之，完成安装和预配置工作，这些在不同发行版之间都是大同小异的，我想基于Slackware，Debian，Red Hat 这几类典型发行版聊聊包管理的差异：
归档格式差异：
Slackware：软件包是tar,gzip压缩包格式归档，扩展名是.tgz ;
Debian: 软件包是ar格式的归档 , 扩展名是 .deb；
Red Hat: 软件包是基于CPIO格式的归档，扩展名是.rpm ;
依赖关系处理方式方式的差异：
Slackware的包管理工具最简单，就是一堆shell脚本集合。由于Slackware本身不引进解决依赖关系并自动下载安装的工具，一些第三方软件工具可以为它提供这方面的功能，分析安装包需要什么库文件，然后寻找什么包提供这些库文件，从仓库获取需要依赖得软件包，虽然这些自动处理很费时，方法原始的多，然而它提供了一个令人满意的解决方案，使用起来就像apt为debian发行版所作的那样便利，第三方工具列表如下：
Swaret
slapt-get
SlackUpdate
Emerde
slackpkg
相比Slackware的包管理方式，Debian的包管理工具套件会更友好，其中底层工具dpkg，安装一个软件包时，会读取deb包内的依赖关系，并给用户以友好的提示，但是获取这些依赖包的工作仍然交给用户来完成，你需要获取全部满足依赖的软件包，并执行 dpkg -i *.deb, dpkg工具才会完成正确的安装配置工作，尽管这些工作令人厌烦，所幸还有更易用得dpkg前端工具来简化操作，使用gdebi能够处理本地安装包并从仓库获取需要的依赖包，使用APT可以从仓库自动下载，配置，安装二进制或者源代码格式的软件包，大大简化了软件管理维护的过程，就连apt-get --help 中的帮助信息都毫不遮掩地地说 “本 APT 具有超级牛力”，常见dpkg前端工具如下：
gdebi
apt,
aptitude,
apt-file
synaptic
Red Hat 包管理工具rpm同debian的dpkg工具一样，也是一个底层工具，同样需要用户来自己来获取全部满足依赖的全部本地软件包，然后执行rpm -i *.rpm来完成全部工作，直到Red hat 修改Yellow Dog Linux的Yellow Dog Updater开发成yum工具之后，才解决了rpm前端工具从无到有的局面，rpmgyum套件虽不及 dpkg/apt 那样强大，但是基本功能都满足，工具统一，使用相对简单，特别是在打包工作上，后续章节我会涉及，最近几年，Red hat赞助得社区发行版fedora 才开发出了功能匹及apt的dnf工具, rpm全部工具集如下：
rpm
mock
yum
dnf
apt(以rpm工具为后端的APT版本)
仓库的创建与管理
对于一个现在的LINUX发行版，没有软件仓库，似乎一件不可思议的事情，软件仓库大体可以分为两类：一种仅仅包含构建脚本，不包含预编译二进制安装包的，另外一种是包含预编译二进制包，和带有编译控制文件的源码包
没有二进制包的仓库
Gentoo就是很典型不适用二进制安装包的发行版本，gentoo的打包其实就是为每个软件编写一个ebuild脚本，Portage包管理系统以执行这些ebuild脚本来完成软件包安装，升级，移出等管理工作, Gentoo的远端仓库其实就是包含一个完整ebuild脚本的集合。
deb包制作与仓库
制作deb包要比rpm包更加繁琐，需要在当前源码目录下创建一个debian目录，里面至少要包含如下文件:
control 定义二进制deb包的名称，编译依赖，安装依赖等信息
changelog 记录软件包修订版记录，以及定义版本号码
compat 定义对 debhelper 最低版本要求
sourcegformat 定义 deb 源代码包格式
copyright 定义版权信息
其中的 rules 是执行入口文件，该文件本质上是一个别名的Makefile，打包工具按照rules文件指定的规则，完成清理编译目录，编译，将软件安装到debian下的临时安装目录等操作，然后调用dpkg-deb依据临时目录的文件来生成deb格式的软件包，所幸的是，dh-make，debhelper等辅助工具可以帮你简化以上的工作,相关工具软件包列表如下：
dpkg-dev
dh-make
debhelper
pbudiler
debbuild
dget
dput
reprepro
关于deb仓库的创建，有很多工具可选，apt-ftparchive, aptly, reprepro, 目前比较常用的是reprepro，操作简单，debian发行版另外一个特别令人津津乐道的是，集合dget，dput等工具集合有机得组成了一个完整的开发流程
rpm包制作与仓库
rpm打包只需要 rpm－build 的工具，和编写一个扩展名为 .spec 规则文件，该文件指导 rpmbuild 命令如何构建和打包软件。yum仓库的创建也是比较简单，执行 createrepo repodirg 就可以创建仓库, 在一个已有的仓库目录下，添加或删除rpm包后，使用createrepo --update repodir/就可以完成仓库的更新,相关软件包如下：
rpm-build
yum-utils
包管理器技术的优缺点
客观地说,包括无论是老牌得Slackware Linux ,还是中流砥柱的Debian Linux，以及成功得商业发行版本Red Hat Linux，还有独树一帜的 Gentoo Linux，包管理系统之间没有绝对得好坏之分，老牌的Slackware 更崇尚KISS哲学，简单到极致；Debian 管理套件工具繁多, 功能丰富，看似凌乱，却不失流程的严谨；Red Hat 的软件包管理工具整齐划一，中规中矩；Gentoo 继承BSD 包管理方式的风采，高度可定制性化，说完了我认为的优点，我倒想谈谈我对这些包管理存在得共性弊端：
无法做到系统应用分离，组件间耦合度太高，随着系统体积的庞大，牵一发而动全身;
无法做到事务性操作,当遇到不可避免的意外，系统包管理系统可能会因此混乱，崩溃；
前瞻未来
随着2013年Docker, CoreOS,等技术开始变得活热，曾经脑海中冒出的自以为是的想法，系统与应用分离,应用与数据分离，这些变得越来越不为奇，Docker虚拟化技术讲传统的应用变成一个个“集装箱”，切换迁移变得更加容易，CoreOS打破了传统发行版的思维，灌注带来新鲜的血液，一时间，FeforagAtomic, Ubuntu/snappy 紧随其后，容器化只是一个阶段，组件化也不是一个遥不可及的梦，或许未来的系统与软件甚至可以像乐高积木一样随意组合.
CoreOS简述
CoreOS有两个root分区，我们暂且称其为root A和root B。CoreOS会与更新服务进行交互，查找更新并自动下载可用的更新，如果初始状态下，系统在root A下启动，更新就会被安装到root B，重新在root B下启动系统就可以完成更新。这个个过程中，被更新的机器不需要从负载集群中移除。同时，为了保证其它应用程序不被打断，CoreOS会通过Linux cgroups限制更新过程中的硬盘和网络IgO。
Ubuntugsnappy 简述
CoreOS的局限性是只能运行容器，而Ubuntugsnappy 理念更加超前，除了满足CoreOS已有特性，借助snappy包，可以扩展到为所有形式的容器或服务供了事务性更新及严格的应用隔离，让snappy应用和Ubuntu Core本身都可以实现原子性升级和回滚。# 前言
无论何时，只要谈起LINUX，就不可避免的谈到UNIX, 谈到发行版，就不得不谈到软件包管理，顺着软件包管理技术的变革趋势，顺便罗列一段软件世界的部分编年史：
unix： 1969年，美国AT&T公司的贝尔实验室
C 语言： 1972年，美国贝尔实验室的 D.M.Ritchie
make： 1977年，贝尔实验室里,斯图亚特·费尔德曼
gnu Autotools：1983年，源自于理查德·斯托曼提出的GNU计划
linux： 1991年，林纳斯·托瓦兹
dpkggapt: 1993年，debian发行版社区开发者伊恩·默多克
rpmgyum: 1997年, originally Red Hat Package Manager
snappy： 2014年, ubuntu 母公司Canonical开发
源码管理阶段
话说在UNIX的上古时代，一群有着开拓精神的开发者，在那个蛮荒时代开垦软件世界的荒地，就像远古的骑士出征，连武器都需要自己准备一样。那个时代还是汇编语言的天下，尽管汇编语言得可读性比起机器码（machine code)有了长足的改进，但是汇编语言本质上还是符号化的机器语言，不同硬件就需要使用不同的汇编语言。先驱们依旧不辞辛苦地上开垦，这种局面一直持续到到C语言的诞生。此后UNIX开创性使用C语言完成重写，正是C语言有着良好可移植性，UNIX获得空前的成功，UNIX版本曾一度多达百余个版本，软件开发也迎来了一个黄金时代, 尽管make工具解决代码编译依赖等工程问题，然而软件的分发依然停留在源码阶段，压缩打包，上传到ftp，下载，解压，然后就是所熟知的 make && make install。
那个时代离我太遥远，我翻阅我所能查看的资料，我一直认为源码分发的时代持续了很久，人们通过调整编译选项，最大程度地编译安装软件，榨取那最后一点可怜的性能提升，但是没人喜欢机械的下载，编译，安装，于是那个时代诞生了BSD系列操作系统（比如 FreeBSD，NetBSD，和 OpenBSD）家族的包管理系统: Ports collections （又称 ports trees 或直接简称 ports) ，通过提供的 makefile 和 patches，以作为一种简单的安装以及创建二进制包，可以轻松地对软件包进行删除、增添或进行其他操作。除了BSD，之后一些Linux发行版有类似的包管理系统，包括 Gentoo的 Portage，Archlinux 的 Arch编译系统(ABS) ，CRUX 的以及 Void Linux 的 Ports。直到现在这些发行版依然存在，依然拥有着于高度的可定制型，以及比起拥有通用二进制包得发行版有着更好的性能，也许有些人不喜欢这种基于源码管理的方式，但是，就像世界任何事物存在的理由一样，存在即有价值！
二进制包与仓库
20世纪90年代初,GNU计划完成除内核外的大部分工作，林纳斯·托瓦兹在1991年10月5日首次发布LINUX内核。但是真正linux仅仅是内核，一个单独linux内核是无法工作，很多组织或社区，将Linux 内核，来自GNU的工具和库，和附加的软件、文档，甚至还有一个窗口系统，窗口管理器，和一个桌面环境结合来自GNU的工具和库，和附加的软件、文档，窗口管理器，和一个桌面环境等组件，集成在一起，构建一个套件，称作发行版，因为绝大部分工具和软件来自由GNU项目，因此也合称GNUglinux. 原则上只要你足够熟悉编译工具的使用，你完全可以通过编译源码得方式安装升级这些组件，但是人是喜欢偷懒的，没人喜欢机械重复的劳动, 使用源码编译方式管理软件是一种耗时耗力的办法，于是那些不满于现状，并且喜欢偷懒的家伙们，开创了通用二进制包管理方式的发型版本，比如，于tgz压缩包的老牌Slackware发行版，基于Dpkg 的(Debian系)，基于RPM 的(Red Hat系), 尽管像 BSD家族(FreeBSD，NetBSD，和 OpenBSD), Gentoo 这类以发行版本依然可以使用二进制包，但那不是他们的初衷。
包管理系统的区别
所有软件包管理系统都能很好完成安装、升级、移除等功能，在这方面除了命令，参数不同之外，其他方面没有特别得差异，总结一句解压缩和释放软件包，将软件包内文件放置到对应的位置，如果软包内包含预配置脚本，根据安装前，安装后，卸载前，卸载后的条件，运行之，完成安装和预配置工作，这些在不同发行版之间都是大同小异的，我想基于Slackware，Debian，Red Hat 这几类典型发行版聊聊包管理的差异：
归档格式差异：
Slackware：软件包是tar,gzip压缩包格式归档，扩展名是.tgz ;
Debian: 软件包是ar格式的归档 , 扩展名是 .deb；
Red Hat: 软件包是基于CPIO格式的归档，扩展名是.rpm ;
依赖关系处理方式方式的差异：
Slackware的包管理工具最简单，就是一堆shell脚本集合。由于Slackware本身不引进解决依赖关系并自动下载安装的工具，一些第三方软件工具可以为它提供这方面的功能，分析安装包需要什么库文件，然后寻找什么包提供这些库文件，从仓库获取需要依赖得软件包，虽然这些自动处理很费时，方法原始的多，然而它提供了一个令人满意的解决方案，使用起来就像apt为debian发行版所作的那样便利，第三方工具列表如下：
Swaret
slapt-get
SlackUpdate
Emerde
slackpkg
相比Slackware的包管理方式，Debian的包管理工具套件会更友好，其中底层工具dpkg，安装一个软件包时，会读取deb包内的依赖关系，并给用户以友好的提示，但是获取这些依赖包的工作仍然交给用户来完成，你需要获取全部满足依赖的软件包，并执行 dpkg -i *.deb, dpkg工具才会完成正确的安装配置工作，尽管这些工作令人厌烦，所幸还有更易用得dpkg前端工具来简化操作，使用gdebi能够处理本地安装包并从仓库获取需要的依赖包，使用APT可以从仓库自动下载，配置，安装二进制或者源代码格式的软件包，大大简化了软件管理维护的过程，就连apt-get --help 中的帮助信息都毫不遮掩地地说 “本 APT 具有超级牛力”，常见dpkg前端工具如下：
gdebi
apt,
aptitude,
apt-file
synaptic
Red Hat 包管理工具rpm同debian的dpkg工具一样，也是一个底层工具，同样需要用户来自己来获取全部满足依赖的全部本地软件包，然后执行rpm -i *.rpm来完成全部工作，直到Red hat 修改Yellow Dog Linux的Yellow Dog Updater开发成yum工具之后，才解决了rpm前端工具从无到有的局面，rpmgyum套件虽不及 dpkg/apt 那样强大，但是基本功能都满足，工具统一，使用相对简单，特别是在打包工作上，后续章节我会涉及，最近几年，Red hat赞助得社区发行版fedora 才开发出了功能匹及apt的dnf工具, rpm全部工具集如下：
rpm
mock
yum
dnf
apt(以rpm工具为后端的APT版本)
仓库的创建与管理
对于一个现在的LINUX发行版，没有软件仓库，似乎一件不可思议的事情，软件仓库大体可以分为两类：一种仅仅包含构建脚本，不包含预编译二进制安装包的，另外一种是包含预编译二进制包，和带有编译控制文件的源码包
没有二进制包的仓库
Gentoo就是很典型不适用二进制安装包的发行版本，gentoo的打包其实就是为每个软件编写一个ebuild脚本，Portage包管理系统以执行这些ebuild脚本来完成软件包安装，升级，移出等管理工作, Gentoo的远端仓库其实就是包含一个完整ebuild脚本的集合。
deb包制作与仓库
制作deb包要比rpm包更加繁琐，需要在当前源码目录下创建一个debian目录，里面至少要包含如下文件:
control 定义二进制deb包的名称，编译依赖，安装依赖等信息
changelog 记录软件包修订版记录，以及定义版本号码
compat 定义对 debhelper 最低版本要求
sourcegformat 定义 deb 源代码包格式
copyright 定义版权信息
其中的 rules 是执行入口文件，该文件本质上是一个别名的Makefile，打包工具按照rules文件指定的规则，完成清理编译目录，编译，将软件安装到debian下的临时安装目录等操作，然后调用dpkg-deb依据临时目录的文件来生成deb格式的软件包，所幸的是，dh-make，debhelper等辅助工具可以帮你简化以上的工作,相关工具软件包列表如下：
dpkg-dev
dh-make
debhelper
pbudiler
debbuild
dget
dput
reprepro
关于deb仓库的创建，有很多工具可选，apt-ftparchive, aptly, reprepro, 目前比较常用的是reprepro，操作简单，debian发行版另外一个特别令人津津乐道的是，集合dget，dput等工具集合有机得组成了一个完整的开发流程
rpm包制作与仓库
rpm打包只需要 rpm－build 的工具，和编写一个扩展名为 .spec 规则文件，该文件指导 rpmbuild 命令如何构建和打包软件。yum仓库的创建也是比较简单，执行 createrepo repodirg 就可以创建仓库, 在一个已有的仓库目录下，添加或删除rpm包后，使用createrepo --update repodir/就可以完成仓库的更新,相关软件包如下：
rpm-build
yum-utils
包管理器技术的优缺点
客观地说,包括无论是老牌得Slackware Linux ,还是中流砥柱的Debian Linux，以及成功得商业发行版本Red Hat Linux，还有独树一帜的 Gentoo Linux，包管理系统之间没有绝对得好坏之分，老牌的Slackware 更崇尚KISS哲学，简单到极致；Debian 管理套件工具繁多, 功能丰富，看似凌乱，却不失流程的严谨；Red Hat 的软件包管理工具整齐划一，中规中矩；Gentoo 继承BSD 包管理方式的风采，高度可定制性化，说完了我认为的优点，我倒想谈谈我对这些包管理存在得共性弊端：
无法做到系统应用分离，组件间耦合度太高，随着系统体积的庞大，牵一发而动全身;
无法做到事务性操作,当遇到不可避免的意外，系统包管理系统可能会因此混乱，崩溃；
前瞻未来
随着2013年Docker, CoreOS,等技术开始变得活热，曾经脑海中冒出的自以为是的想法，系统与应用分离,应用与数据分离，这些变得越来越不为奇，Docker虚拟化技术讲传统的应用变成一个个“集装箱”，切换迁移变得更加容易，CoreOS打破了传统发行版的思维，灌注带来新鲜的血液，一时间，FeforagAtomic, Ubuntu/snappy 紧随其后，容器化只是一个阶段，组件化也不是一个遥不可及的梦，或许未来的系统与软件甚至可以像乐高积木一样随意组合.
CoreOS简述
CoreOS有两个root分区，我们暂且称其为root A和root B。CoreOS会与更新服务进行交互，查找更新并自动下载可用的更新，如果初始状态下，系统在root A下启动，更新就会被安装到root B，重新在root B下启动系统就可以完成更新。这个个过程中，被更新的机器不需要从负载集群中移除。同时，为了保证其它应用程序不被打断，CoreOS会通过Linux cgroups限制更新过程中的硬盘和网络IgO。
Ubuntugsnappy 简述
CoreOS的局限性是只能运行容器，而Ubuntugsnappy 理念更加超前，除了满足CoreOS已有特性，借助snappy包，可以扩展到为所有形式的容器或服务供了事务性更新及严格的应用隔离，让snappy应用和Ubuntu Core本身都可以实现原子性升级和回滚。