您可以使用多种方法指定软件包的安装位置,而且很重要的一点是能够在安装时动态更改安装基本位置。如果正确实现了此功能,管理员便可以轻松安装多个版本和多个体系结构。
本节首先讨论常用方法,然后讨论能够改进异构系统上的安装的途径。
负责安装软件包的管理员可以使用管理文件来控制软件包安装。然而,作为软件包设计者,您需要了解有关管理文件的信息,并了解管理员如何能够改变您计划的软件包安装。
管理文件告诉 pkgadd 命令是否执行它通常执行的任何检查或提示。因此,管理员在使用管理文件之前应该充分了解软件包的安装过程和涉及的脚本。
缺省基本管理文件随 SunOS 操作系统一起提供,位于 /var/sadm/install/admin/default 中。该文件建立了与软件产品安装有关的最基本级别的管理策略。随操作系统一起提供的该文件如下所示:
#ident "@(#)default 1.4 92/12/23 SMI" /* SVr4.0 1.5.2.1 */ mail= instance=unique partial=ask runlevel=ask idepend=ask rdepend=ask space=ask setuid=ask conflict=ask action=ask basedir=default |
管理员可以编辑此文件以建立新的缺省行为,或者创建一个不同的管理文件并使用 pkgadd 命令的 -a 选项指定其存在。
在一个管理文件中可以定义 11 个参数,但并非所有参数都必须定义。有关更多信息,请参见 admin(4)。
basedir 参数指定在安装软件包时如何派生基目录。大多数管理员都将此参数保留为 default,但可以将 basedir 设置为以下值之一:
ask,表示始终要求管理员提供基目录
绝对路径名
包含 $PKGINST 构造的绝对路径名,表示始终安装到派生于软件包实例的基目录
如果带有参数 -a none 调用了 pkgadd 命令,则该命令始终要求管理员提供基目录。遗憾的是,这还会将文件中的所有参数设置为缺省值 quit,而这可能会导致其他问题。
管理员可使用管理文件来控制系统上正安装的所有软件包。遗憾的是,软件包设计者经常提供一个替代的缺省管理文件,而没有考虑管理员的愿望。
软件包设计者有时会提供一个替代管理文件,以便他们自己(而不是管理员)能够控制软件包的安装。由于缺省管理文件中的 basedir 条目会覆盖所有其他基目录,因此它提供了一种在安装时选择适当基目录的简单方法。在早于 Solaris 2.5 发行版的所有 Solaris OS 版本中,这种方法被认为是控制基目录的最简单方法。
然而,您必须接受管理员的有关产品安装的希望。提供一个临时的缺省管理文件以便控制安装会导致管理员觉得不受信任。您应该使用 request 脚本和 checkinstall 脚本在管理员的监督下控制这些安装。如果 request 脚本如实地使管理员参与安装过程,System V 打包过程将同时满足管理员和软件包设计者的需求。
pkginfo 文件都必须以如下所示的条目形式包括一个缺省基目录:
BASEDIR=absolute_path |
这只是缺省基目录,可由管理员在安装期间更改。
尽管某些软件包需要多个基目录,但使用此参数定位软件包的好处是,当安装开始的时候,能够保证基目录作为一个有效的目录就位并可写。服务器和客户机的基目录的正确路径以保留环境变量的形式供所有过程脚本使用,并且 pkginfo -r SUNWstuf 命令显示软件包的当前安装基本位置。
在 checkinstall 脚本中,BASEDIR 即是 pkginfo 文件中定义的该参数(该参数尚未根据条件赋值)。为了检查目标基目录,需要使用 $ {PKG_INSTALL_ROOT} $BASEDIR 构造。这意味着 request 或 checkinstall 脚本可以在安装环境下更改 BASEDIR 的值,并且可以获得可预测的结果。当调用 preinstall 脚本时,BASEDIR 参数是指向目标系统上实际基目录的完全根据条件设置的指针,即使该系统是客户机也是如此。
对于不同的 SunOS 操作系统发行版,request 脚本以不同方式利用 BASEDIR 参数。为了在 request 脚本中测试 BASEDIR 参数,应该使用下面的代码来确定正在使用的实际基目录。
# request script constructs base directory if [ ${CLIENT_BASEDIR} ]; then LOCAL_BASE=$BASEDIR else LOCAL_BASE=${PKG_INSTALL_ROOT}$BASEDIR fi |
如果一个软件包需要多个基目录,您可以使用参数化路径名建立这些目录。此方法已经相当流行,尽管它具有以下缺点。
具有参数化路径名的软件包的行为方式通常类似于绝对软件包,但 pkgadd 命令会像处理可重定位的软件包一样处理该软件包。必须定义 BASEDIR 参数(即使没有使用)。
管理员无法使用 System V 实用程序确定软件包的安装基本位置(pkginfo -r 命令不起作用)。
管理员无法使用既定的方法重定位软件包(它称为可重定位的软件包,但是其行为方式与绝对软件包相同)。
多体系结构或多版本的安装要求对每个目标基目录进行意外事件计划,这通常意味着使用多个复杂的类操作脚本。
尽管确定基目录的参数是在 pkginfo 文件中定义的,但可以被 request 脚本修改。这是此方法广受欢迎的主要原因之一。然而,此方法的缺点会长期存在,您应该在迫不得已的情况下才考虑使用此配置。
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/ EZDIR=/usr/stuf/EZstuf HRDDIR=/opt/SUNWstuf/HRDstuf VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert980707141632 |
: 1 1758 1 d none $EZDIR 0775 root bin 1 f none $EZDIR/dirdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/usrdel 0555 bin bin 40 773 751310229 1 f none $EZDIR/filedel 0555 bin bin 40 773 751310229 1 d none $HRDDIR 0775 root bin 1 f none $HRDDIR/mksmart 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mktall 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mkcute 0555 bin bin 40 773 751310229 1 f none $HRDDIR/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 f none /etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
如有必要,任何具有多个版本或多种体系结构的软件包都应该设计为遍历基目录。遍历基目录意味着如果基目录中已经存在要安装的软件包的以前版本或不同体系结构,则要安装的软件包会解决此问题,方法可能是使用稍微不同的名称创建一个新的基目录。Solaris 2.5 和兼容发行版中的 request 和 checkinstall 脚本能够修改 BASEDIR 环境变量。对于 Solaris OS 的任何更早版本,情况则不是这样的。
即使在 Solaris OS 的较早版本中,request 脚本也有权在安装基本位置中重新定义目录。request 脚本可以采用仍然支持多数管理首选项的方法完成此操作。