Solaris的apt-get, IPS的pkg

在Ian.Murdock的力推之下，OpenSolaris也推出了自己的网上升级系统--IPS，在功能和用法上，IPS和apt-get功能基本一致。目前OpenSolaris发行，IPS处于中心的地位，这是由Sun的资深工程师Stephen.Hahn（同时也是SMF的设计者）来设计的，目的是最大程度的推广Solaris。在OpenSolaris的社区里面，围绕着它产生了一堆小的projects。

IPS根据功能，可以分为两个部分。基于client端的程序，叫做pkg(1)，同时它还提供了一个http server程序，主要是用于维护Solaris的各种版本的升级包，并且负责和client端要升级的pkg请求通信，向下发送packages。IPS的实现是完全采用Python来实现的。具体源程序在/usr/lib/python2.4/vendor-packages/pkg里面。

相对于传统的SVR4包来说，IPS显得更加容易使用，维护的费用更低。但是，对于商业版本的Solaris来说，可能短时间内不会采用这种方式安装/升级包。本来嘛，IPS的产生就是为了争取最大程度的推广发行OpenSolaris，不管这个目的是否能够达成，IPS本身作为一个完整而轻量级的设计理念，还是值得学习并且推广的。相对于Ubuntu等Debian Linux系开源系统，IPS本身作为一个正在开发的系统，相比较来说还不是那么的完善，功能和性能都有待提高。但毕竟它提供了容易安装/升级包的方法，而且，它还和Solaris的ZFS系统紧密结合起来，利用ZFS的功能，对用户提供最大程度的数据保护。比如你安装或升级失败了，还可以利用它的ZFS文件接口，回滚到升级开始的状态。

下面，对于IPS的结构做一个简单的分析。
在客户端，pkg的组织结构可以从/var/pkg目录里面看出来。

# ls
catalog  file  cfg_cache  download index

其中的catalog是各个不同的IPS站点包含的软件包的索引，里面的内容如下

# cd catalog/opensolaris.org/
# ls
attrs    catalog
# more catalog
V pkg SUNWdvdrw 5.21.4.10.8,5.11-0.86:20080426T173208Z
V pkg SUNWdvdrw 5.21.4.10.8,5.11-0.75:20071114T201614Z
V pkg SUNWdvdrw 5.21.4.10.8,5.11-0.86:20080422T205204Z
V pkg SUNWdvdrw 5.21.4.10.8,5.11-0.79:20080205T153550Z
...

可能会觉得这个包格式定义的有点奇怪，这个在IPS里面有一个专有的名字：FMRI，用于区分不同的包和同样的包但是不同版本的情况。

其他的文件，cfg_cache，里面规定了各个不同的IPS站点的属性，比如名字，ssl证书情况，是否有效等等情况。pkg目录里面是所有安装包的情况，其中的entire就是整个系统软件包的一个别名，当运行pkg image-update来升该级整个系统的时候，实际上就是升级这个entire软件包。在pkg/pkg_name目录里面还可能有安装的各个版本的情况（当然是以FMRI的情况给出），再里面如果还有文件installed，实际上是就是标识软件包已经被装上了。比如

# pkg verify SUNWzfs
#  <--- 这说明已经安装了SUNWzfs包
# cd pkg/SUNWzfs//
# rm -rf installed
# pkg verify SUNWzfs
pkg: 系统中没有安装任何与您指定的以下模式
匹配的软件包。

      SUNWzfs
#

index目录就是一个索引目录，标识安装了软件包的名字和版本，每次安装/升级后，pkg都要更新这个索引。还有，file目录，在pkg install 或者image-update的过程中，从IPS server上下载文件放到这个目录下，当然，这些文件都不是明文存在的，它们是已经通过LAMZ算法算法压缩好了的，并且每一个都有一个独立的FMRI。当client端把这些文件下载完后，再通过解压缩，还原文件，copy到要安装的目录下。具体要安装到那个目录下，pkg是通过plan的形式预先算出，所谓plan就是在server端的pkg目录里面每个包的一些信息，还是以SUNWzfs为例

 # pwd
/ips/repo/repo/pkg/SUNWzfs
# cat 0.5.11%2C5.11-0.109%3A20090305T202705Z
...
file dd51cdbf92ce22e6c04c5142528b26b9c16edc40 chash=ee78226cedcd06cc1ba4a29e408b1c00eb3ac7eb elfarch=i386 elfbits=32 elfhash=512da5400be7e9dc731dccfeca9480172098f1e2 group=sys mode=0755 owner=root path=usr/lib/devfsadm/linkmod/SUNW_zfs_link.so pkg.csize=2336 pkg.size=7804 variant.arch=i386
link path=usr/lib/libzpool.so target=libzpool.so.1 variant.arch=i386
...

根据这个文件，就可以知道要把文件装在什么目录了。从上面这个文件中，我们就可以知道pkg的工作流程了。

 pkg运行->[向IPS server进行认证]->从server更新catalog->找到要安装的包的FMRI->根据dependency来计算所有的 depend包->得到所有包的FMRI->下载对应FMRI的包s的plan信息（如上所示）->生成plan->下载文件 ->解压缩->在client端按照要求生成文件->安装完所有的包->更新state信息->更新index.

从上面的SUNWzfs包的plan文件中，我们可以看到一些很奇怪的内容"file dd51cd....."，这个是什么东西呢？这个实际上就是对应文件在server端的存在形式。

#cd /ips/repo/repo/file/dd/51cdbf
# ls
dd51cdbf92ce22e6c04c5142528b26b9c16edc40
# file dd51cdbf92ce22e6c04c5142528b26b9c16edc40
dd51cdbf92ce22e6c04c5142528b26b9c16edc40:       gzip compressed data - deflate method , max compression

# gunzip dd51cdbf92ce22e6c04c5142528b26b9c16edc40
# file dd51cdbf92ce22e6c04c5142528b26b9c16edc40
ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available

可以看到它实际上就是一个ELF文件。