[This is a reply to Grissiom post about slackware’s package-management]
Foresight Linux 跟 Slackware Linux 的根本不同在于两者的定位不同，Foresight 的目标是一个简单易用的桌面系统，而 Slackware 应该是给 geek 用的。所以，好多争论其实是没有意义的。
而 conary 跟 slackware 的包管理，也有着完全不同的目标。conary 的重点在于自动化(automatic)，跟 slackware 是背道而驰。所以对两者的比较只能是技术上的讨论，无法说谁优谁劣。
下边是具体内容。
管理文件就不用说了，每一个包管理都有这个功能 (否则可以称之为 Windows)。
依赖处理
======
Slackware 是不处理依赖的，而 conary 就强在处理依赖上。conary 把整个系统都归在自己的管理下，不仅能处理单个包的依赖，还能保证整个系统都处于 consistent 的状态。
能做到这一点，是因为 conary 里面 group 的概念。一个 group 本质上只是包含一堆包的一个包。注意，对 conary 来说，group 也是一个软件包。能对普通包进行的操作，也能在 group 上进行。而基于 conary 的发行版，其整个系统是由一个 group 定义的，通常叫做 group-什么什么-dist，比如 group-gnome-dist (定义 GNOME 版 Foresight 的 group)、group-xfce-dist (定义 XFCE 版 Foresight 的 group)。正因为此，conary 能够管理整个系统，使得系统范围内的依赖关系都是良好的。
另外一点，conary 是在文件级别处理依赖的 (跟 slackware 是两个极端)。上篇文章提过了，这里不再赘述。
自动还是不自动？
============
可以看出，slackware 进行各种操作主要是靠用户运行各种(自创或者外来的)脚本。毫无疑问，这样非常”爽”，符合 hacker 精神 (我也喜欢 :-)。
不过这种方式对于系统管理员 (要维护大量的机器) 来说，无疑是个噩梦，会”极大的束缚生产力”。作为一个 SA，他必须为自己的各种任务创造各种各样的脚本，或者从别的 SA 那借鉴一些轮子 (因为大家的许多任务还是差不多的嘛)。这些脚本或者命令都是人工管理的，维护成本会很高。如果 SA 跳槽了，新来的 SA 八成是个杯具…
与此相反，conary 的设计哲学是，common 的情景都由它来做，然后 SA 把需要特殊注意的事情说明白，就行了。所以在 conary 系统上，会看到各种操作都是能简单就简单，能用模板就用模板。
举例来说
======
比如打包的时候，许多软件都是同样的 configure; make; make install，所以 conary 提供了一个 recipe template，叫 AutoPackageRecipe，表示用 autotools 来打包的软件就可以用这个模板。只需要给 conary 一个 tarball，它会自动调用模板里定义的 Configure/Make/MakeInstall 函数来打包。请参考 Foresight Linux 的 automake 包。注意它根本没有指明如何 make、如何 install。
再举一个极端的例子。用于指定 tarball 位置的 URL，原则也是能简则简：
＊ 添加一个tarball，用 addArchive 函数。’正常’的写法是：
addArchive(’ftp://ftp.gnu.org/gnu/automake/automake-1.11.tar.bz2’)
* 如果遵循好的编程习惯，最好写成：
addArchive(’ftp://ftp.gnu.org/gnu/automake/automake-%(version)s.tar.bz2’)
* 但是，其实只需要一个目录，conary 会自动去找压缩包：
addArchive(’ftp://ftp.gnu.org/gnu/automake/’)
* 其实… conary 能识别一系列的 mirror
addArchive(‘mirror://gnu/automake/’)
或者 addArchive(‘mirror://gnu/%(name)s/’)
这只是一个细节问题，但它反映了 conary 行事的惯例。上边的例子同样可以参考 automake 包。
常用操作
=====
可以看到，slackware 中许多操作都是’简单’的 grep/find 等命令的组合，而 conary 系统中，则是用 conary 提供的一系列命令。conary 提供了命令行的接口，以方便 scripting；而且也提供 API 接口，可以在代码中调用，比如 PackageKit 的 conary 后端，注意这一行，
from conary import dbstore, queryrep, versions, updatecmd
在命令行下：
* 查询一个 package 包含了哪些文件
conary query gedit –ls
* 查询某个文件是由哪个包提供的
conary query –path /usr/bin/gedit
* 查询一个包有哪些依赖，提供了哪些依赖
conary query –deps gedit
* 检查一个包是不是完好无损
conary verify gedit
* 查询源里边包的信息
conary repquery gedit
等等…
关于回滚
=====
回滚只是 conary 细粒度依赖处理的一个表现而已。conary 能保证系统处在一个已知的、确定的状态中 (consistent)，回滚无非是在当前状态跟上一个状态的转变。
比如安装了一个包(volti)，它同时带来了好多依赖(pyalsaaudio, python-xlib)。稍后的回滚能撤销整个操作，也就是不仅会删除 volti，随它而来的 pyalsaaudio 和 python-xlib 也会被同时删除。再比如系统范围的 updateall，被回滚的话，会被整个撤销。在其他的包管理下，就只能来个 for 循环，统统 downgrade 回旧版本了。
conary 提供了 sync 命令，能把一个包同步到某个版本去。注意 group 也是一个包，所以如果 sync 的对象是 group-x-dist 的话，能保证整个系统都处于指定版本上。软件包的任何损坏 (比如不同版本的库被错误安到了一块)，都可以侦探出来 (上边提到的 conary verify)，都可以修复。这个特点是简单粗暴的卸载重装无法比拟的。
“Each one uses different package formats that cannot understand each other”
=======
conary 能够理解 rpm 和 deb 格式，能够把这些格式的包转换成 conary 系统可用的包。比如这个 linuxqq 的包，是直接用了腾讯发布的 rpm 包 (没有经过再次编译)。比如这个 picasa 包，是用了 deb 包，也没有再次编译。比如这个 libgnome 包，用了 src.rpm，利用 rpm 的 spec，重新编译形成 conary 包。
Foresight Linux 跟 Slackware Linux 的根本不同在于两者的定位不同，Foresight 的目标是一个简单易用的桌面系统，而 Slackware 应该是给 geek 用的。所以，好多争论其实是没有意义的。
而 conary 跟 slackware 的包管理，也有着完全不同的目标。conary 的重点在于自动化(automatic)，跟 slackware 是背道而驰。所以对两者的比较只能是技术上的讨论，无法说谁优谁劣。
下边是具体内容。
管理文件就不用说了，每一个包管理都有这个功能 (否则可以称之为 Windows)。
依赖处理
======
Slackware 是不处理依赖的，而 conary 就强在处理依赖上。conary 把整个系统都归在自己的管理下，不仅能处理单个包的依赖，还能保证整个系统都处于 consistent 的状态。
能做到这一点，是因为 conary 里面 group 的概念。一个 group 本质上只是包含一堆包的一个包。注意，对 conary 来说，group 也是一个软件包。能对普通包进行的操作，也能在 group 上进行。而基于 conary 的发行版，其整个系统是由一个 group 定义的，通常叫做 group-什么什么-dist，比如 group-gnome-dist (定义 GNOME 版 Foresight 的 group)、group-xfce-dist (定义 XFCE 版 Foresight 的 group)。正因为此，conary 能够管理整个系统，使得系统范围内的依赖关系都是良好的。
另外一点，conary 是在文件级别处理依赖的 (跟 slackware 是两个极端)。上篇文章提过了，这里不再赘述。
自动还是不自动？
============
可以看出，slackware 进行各种操作主要是靠用户运行各种(自创或者外来的)脚本。毫无疑问，这样非常”爽”，符合 hacker 精神 (我也喜欢 :-)。
不过这种方式对于系统管理员 (要维护大量的机器) 来说，无疑是个噩梦，会”极大的束缚生产力”。作为一个 SA，他必须为自己的各种任务创造各种各样的脚本，或者从别的 SA 那借鉴一些轮子 (因为大家的许多任务还是差不多的嘛)。这些脚本或者命令都是人工管理的，维护成本会很高。如果 SA 跳槽了，新来的 SA 八成是个杯具…
与此相反，conary 的设计哲学是，common 的情景都由它来做，然后 SA 把需要特殊注意的事情说明白，就行了。所以在 conary 系统上，会看到各种操作都是能简单就简单，能用模板就用模板。
举例来说
======
比如打包的时候，许多软件都是同样的 configure; make; make install，所以 conary 提供了一个 recipe template，叫 AutoPackageRecipe，表示用 autotools 来打包的软件就可以用这个模板。只需要给 conary 一个 tarball，它会自动调用模板里定义的 Configure/Make/MakeInstall 函数来打包。请参考 Foresight Linux 的 automake 包。注意它根本没有指明如何 make、如何 install。
再举一个极端的例子。用于指定 tarball 位置的 URL，原则也是能简则简：
＊ 添加一个tarball，用 addArchive 函数。’正常’的写法是：
addArchive(’
addArchive(’
addArchive(’
或者 addArchive(‘mirror://gnu/%(name)s/’)
这只是一个细节问题，但它反映了 conary 行事的惯例。上边的例子同样可以参考 automake 包。
常用操作
=====
可以看到，slackware 中许多操作都是’简单’的 grep/find 等命令的组合，而 conary 系统中，则是用 conary 提供的一系列命令。conary 提供了命令行的接口，以方便 scripting；而且也提供 API 接口，可以在代码中调用，比如 PackageKit 的 conary 后端，注意这一行，
from conary import dbstore, queryrep, versions, updatecmd
在命令行下：
* 查询一个 package 包含了哪些文件
conary query gedit –ls
* 查询某个文件是由哪个包提供的
conary query –path /usr/bin/gedit
* 查询一个包有哪些依赖，提供了哪些依赖
conary query –deps gedit
* 检查一个包是不是完好无损
conary verify gedit
* 查询源里边包的信息
conary repquery gedit
等等…
关于回滚
=====
回滚只是 conary 细粒度依赖处理的一个表现而已。conary 能保证系统处在一个已知的、确定的状态中 (consistent)，回滚无非是在当前状态跟上一个状态的转变。
比如安装了一个包(volti)，它同时带来了好多依赖(pyalsaaudio, python-xlib)。稍后的回滚能撤销整个操作，也就是不仅会删除 volti，随它而来的 pyalsaaudio 和 python-xlib 也会被同时删除。再比如系统范围的 updateall，被回滚的话，会被整个撤销。在其他的包管理下，就只能来个 for 循环，统统 downgrade 回旧版本了。
conary 提供了 sync 命令，能把一个包同步到某个版本去。注意 group 也是一个包，所以如果 sync 的对象是 group-x-dist 的话，能保证整个系统都处于指定版本上。软件包的任何损坏 (比如不同版本的库被错误安到了一块)，都可以侦探出来 (上边提到的 conary verify)，都可以修复。这个特点是简单粗暴的卸载重装无法比拟的。
“Each one uses different package formats that cannot understand each other”
=======
conary 能够理解 rpm 和 deb 格式，能够把这些格式的包转换成 conary 系统可用的包。比如这个 linuxqq 的包，是直接用了腾讯发布的 rpm 包 (没有经过再次编译)。比如这个 picasa 包，是用了 deb 包，也没有再次编译。比如这个 libgnome 包，用了 src.rpm，利用 rpm 的 spec，重新编译形成 conary 包。