11.4 高级软件包管理系统
23.5.3
自动安装软件包
APT、yum和Red Hat Network这样的基础软件包管理系统目标都相同：
— 简化定位和下载软件包的过程；
— 自动进行系统更新或者升级；
— 方便管理软件包间的依赖关系。
显然，这几种系统所面对的不仅仅是客户端的命令。它们都要求发行版本的维护人员以一种统一的方式组织好提供的软件，这样客户机就能访问和推断软件有几种程序能让您软件包自动升级。其中最好和最流行的两种是Red Hat Network和Debian的apt-get。
既然没有一家提供商能包含整个“Linux的软件世界”，所以这几种系统都允许有多个软件库。软件库可以就在本地网络，这些系统为营造用户自己的内部发布系统提供了一个良好的基础。
|
|
Red Hat Network同Red Hat Enterprise Linux紧密地结合在了一起。它是一种要付费的商业服务，而且在吸引人的GUI和自动化的能力方面，提供了比APT和yum更多的功能。遗憾的是，在这些表面现象之下掩盖着相当神秘的黑箱。它的客户机能够访问yum和APT的软件库，这种能力使得CentOS这样的发行版本可以让客户端的GUI适用于Red Hat Network之外的其他软件库。 |
Red Hat Network同Red Hat发行版本紧密地结合在了一起。它是一种要付费的商业服务，而且在吸引人的GUI和自动化的能力方面，提供了比apt-get更多的功能。遗憾的是，在这些表面现象之下掩盖着相当神秘的黑箱。
APTapt-get比Red Hat Network有更好的文档说明，更值得注目的是，它的移植性更好移植性更强，而且是免费的。在您可以用它来做什么这方面，它也更为灵活。APT源自于apt-get和Debian以及和dpkg结合得最紧密，但是它已经扩展到能够支持也有使用RPM的版本，在我们举例的发行版本上，都有合适的APT版本可用。对于软件发布来说，APT是目前我们可以有的最接近通用标准的工具。能够用于Red Hat和Debian。如果您想要建立自己的自动化的软件包安装网络，我们建议您使用apt-get的这个版本。了解更多的知识参考23.6.4节。
yum的功能类似APT，但它专门用于RPM。尽管如果把它指到格式正确的软件库上，它能在任何基于RPM的系统上运行，但它默认只是Fedora的软件包管理工具。
在做比较的时候，人们一般把yum当做是APT用于RPM的版本，但这么认为并没有明确有说服力的技术原因。yum在RPM世界的根基更深，这让它成为领头羊也在情理之中。在2005年的早些时候，APT-RPM的最初开发者Gustavo Niemeyer放弃了它，转而去开发一个更为复杂的系统（labix.org的Smart Package Manager，这个软件包管理工具还没有成为主流，但人们普遍期望它是下一个重大软件），这给APT-RPM的未来蒙上了一层阴影。最后Panu Matilainen接手继续开发APT-RPM，这个软件项目的开发工作目前再度活跃起来。
我们喜爱APT，如果您想要建立自己的软件包自动发布网络的话，不管您的站点当前在用的Linux发行版本是怎样的，APT都是一个供您考虑的可靠选择。
|
|
SUSE在软件包管理领域做得并不好。它虽然使用RPM包，但是以前的发行版本只支持通过SUSE自己的YaST Online Update工具做系统升级。经过一番兼容并包之后，SUSE最近已经在某种程度上增加了对yum、APT-RPM和Novell自己的ZENworks Linux Management代理的支持，而ZENworks成为SUSE首要的软件更新管理工具（了解命令行界面可参见rug）。 |
SUSE is
something of a lame duck in the package management domain. It uses RPM packages,
but previous releases supported only SUSE’s own
YaST Online Update tool for performing system updates. In a blaze of
promiscuity, SUSE has recently added some
degree of support for yum, APT-RPM, and Novell’s own ZENworks Linux Management
agent, with ZENworks being the primary update manager. (See rug for a
command-line interface.)
ZENworks属于更大的一个产品线，这个产品线体现出Novell要在跨平台配置管理领域里占据主导地位的努力。它是您最好的选择吗？如果您采用了Novell的产品，而且对付费支持感兴趣的话，或许能算吧。那些想要保持软件包的管理能够免费而且没有倾向性的站点，可能会研究前面提到的Smart Package Manager。
11.4.1 软件包的库
Linux的各个发行版本都维护着自己的软件库，这些软件库和发行版本选择的软件包管理系统携手工作。软件包管理系统的默认配置通常指向一个或者几个由发行商控制的知名Web或FTP服务器。
不过，这样的软件库应该包含什么内容却并不那么显而易见。它们应该只包括正式的、主要发布的软件包吗？还是正式发布加上当前的安全更新？还是正式发布中所有软件包的最新版本？没有得到发行方的官方支持，但却有用的第三方软件该有吗？该有源代码吗？该有针对多种硬件体系结构的二进制软件吗？当运行apt-get upgrade或者yum upgrade更新系统的时候，到底应该做些什么？
一般来说，软件包管理系统必须解决上述所有问题，而且必须让站点很容易选择出自己规定的专门交叉集合，以此作为自己的“软件圈子”。下面的概念有助于理清这个过程的脉络。
— “发布（release）”是对软件包的世界所做的一个前后一致的快照。在Internet时代之前，有名有姓的操作系统都多少不怎么容易变化，某个时期就是一个固定的版本，安全补丁则单独提供。现如今，发布是一个更加模糊的概念。发布随着软件包的更新而不断演变。有些发布，比如Red Hat Enterprise Linux，特意做成发展变化很缓慢。在默认情况下，这类发布只融入安全更新。而另外一些发布，比如beta版发布，变化频繁而且幅度大。但是在所有情况下，发布都是基线，是目标，是“我想更新我的系统，让它看上去像的那个东西”。
— “组件（component）”是一次发布里的软件子集。各个发行版本对自身的划分不尽相同，但是它们却都会明确区分核心软件和额外软件，核心软件由发行商做保障，而额外软件则由更为广泛的社群来提供。在Linux界还有一种区分，这就是在发布里，有开放源代码的部分和受某种限制性许可证协议影响的部分。
从系统管理的角度来看，特别要注意的是仅仅包含安全补丁的那些最稳定的软件组件。有些发布可以把一个安全组件同一个稳定不变的基线组件组合起来，创建出一个相对稳定的发行版本。
— “体系结构（architecture）”代表一种特定类型的硬件。希望属于一种体系结构的机器都很相似，它们都能执行相同的二进制代码。发布针对不同的体系结构有专门的版本，例如，“Fedora Core 5 for the i386 architecture（针对i386体系结构的Fedora Core 5）”。因为发布可以细分为若干组件，所以每个组件也对应各种体系结构有专门的版本。
— “单个软件包”是组成组件的基本元素，因此它们也间接成为组成发布的基本元素。软件包通常特定于某种体系结构，其版本与主发布无关，也和其他软件包没有关系。软件包和发布间的对应关系由网络上软件库的设置方式暗中决定。
有些软件组件并不是由发行版本的提供方来维护的（例如，Debian的“contrib”或者Fedora的“extras”），这就带来了问题，这些软件组件同核心OS发布的关系如何确定。它们真的能够叫做特定发布的“一个组件”吗？从管理软件包的角度来看，答案很清楚：extras确实算组件。它们和一个特定的发布有关系，而且它们随发布一起变化。从系统管理的立场来说，对这类软件包的控制独立于发布要引起注意，但是它不会影响到软件包的发行体系。
除了以“拉”方式自动安装软件包的工具之外，还有一些工具虽然不特别针对软件包，但却能让您在客户机上轻松地执行与软件包有关的任务。其中最有名的一种叫做cfengine，它是一种能让您在许多主机上运行任务的工具。它不仅仅针对软件包的安装，对于相当多的系统管理任务来说，它都能派上用场。参考以下网址了解更多信息：
http://www.iu.hio.no/cfengine
2311.54.4
2 Red Hat NetworkRHN：Red Hat网络
随着Red Hat远离消费类的Linux业务，Red Hat
Network（RHN）已经成为Red Hat
Enterprise Linux的系统管理平台。您要通过订购方式购买对RHN的访问权。人们把Red Hat Network描述为Red Hat所做的一种努力，就是找一个理由给您，让您宁愿购买盒装的Red Hat Linux正式版，而不是从网上下载它。您按月或者按年定购服务，反过来您也会保持和Red Hat主控软件树的更新。既然“出租软件”似乎是现下最流行的风气，那么看到Red Hat把Linux推到了最前沿的软件收费模式上也就理所当然了。
在最简单的层面上，您只要把Red Hat Network当作一个色彩斑斓的Web门户网站和邮递列表来用就行了。按照这种方式来用它的话，它同各个UNIX厂商多年来所支持的补丁通知邮递列表没有太大的区别。但是如果您愿意关注的话但是如果您愿意花钱的话，会享受到更多的功能。
Red Hat Network提供了一种非常漂亮的GUI界面，供下载新软件包使用（，还可以代之以用命令行命令它还提供了一种命令行的备选方式）。它甚至可以无需人工干预它甚至可以在不需要人工干预的情况下，下载和安装新软件包。一旦您取得了注册，您的机器就会得到它们所需要的全部补丁和bug修正，而您不必放下手中的Quake游戏。自动注册的不利一面是要由Red Hat来决定您需要什么样的补丁。您可能要考虑您到底对Red Hat（以及被他们打包的软件产品的维护方）有多大的信任程度，相信他们不会把事情搞糟。鉴于过去在碰到比如应该提供哪种编译器这样的小事情时，Red Hat所做的一些有趣的选择，有些人可能会持怀疑态度。一种可行的折衷方法可能是，让机构内的一台机器注册自动更新功能。您可以定期从那台机器得到瞬态映像，按内部发布的候选来进行测试。
一种合理的折衷方法可能是，让单位内的一台机器注册自动更新功能。您可以定期从那台机器得到快照，按内部发布的可能候选来进行测试。不过，在着手这么做之前，要先研究一下Red Hat的许可证协议（从www.redhat.com/licenses可以获得）。您可能会对下面的内容感到吃惊：Red Hat称其对于通过RHN发布的开放源代码软件享有自己的权益，但却没有提您已经同意让Red Hat随意审查您的系统。要注册Red Hat Network，要么可以运行Red Hat所带的rhn_register程序，要么可以使用rhn.redhat.com上的web界面。如果您处于防火墙的后面，可以运行rhn_register --configure配置一个代理；否则，使Red Hat的GUI启动并运行。
一旦已经注册了您的系统，那么运行Red Hat的更新代理程序up2date来管理注册服务、下载软件包，以及改变您的配置。您可能也会注意到在您的机器上运行着一个新的守护进程rhnsd。这就是轮询Red Hat的站点获得新更新的守护进程。
遗憾的是，Red Hat Network尚不足以提供您想要从一项更新服务所能得到的每种功能。最显而易见的是，您不能使用它来升级到Red Hat的新版本（例如，从7.1升级到7.2）。Debian对应于RHN的apt-get提供这项功能已经有一段时间了，它似乎干得不赖。总体而言，apt-get是比RHN更成熟的产品，但是RHN发展得很快。
2311.4.36
apt-getAPT：高级软件包工具：自动下载和安装
APTapt-get（Advanced
Package Tool，高级软件包工具）是最成熟的软件包管理系统。用一条apt-get命令就可以更新整个一个系统的所有软件，甚至（就和使用RHN一样）还可以不需要人工干预，保持您的机器不断得到更新。Debian最棒的特色之一。它自动下载和安装更新和新软件包。如果新软件包依赖于其他软件包，apt-get还能替您获得并安装它们。实际上，有了apt-get，用一条命令就可以将您的机器升级到最新版的Debian，甚至能让您的机器在没有人干预的情况下保持更新。这个系统在整体上被称为API，即Advanced
Packaging Tool（高级包管理工具）。
因为它APT源自于Debian的世界，所以它apt-get原本只支持.deb格式的软件包。不过，现在APT它已经被移植到了RPM软件包的机制上。这个版本叫做APT-RPMapt-rpm，可以从apt-rpm.org
http://distro.conectiva.com/projetos/42
得到它。本章后面将会介绍yum系统，它提供了类似的功能，但却基于RPM，Fedora发布直接支持yum系统。在yum和APT-RPM之间进行选择的时候，您的站点和发行版本内部侧重的不同，要比系统间技术上的差异重要得多。要采用得到很好支持和简便易行的方式。
遗憾的是，apt-rpm没有原来的apt-get那么有用，因为它的服务器端的设施开发得不好。为了在Debian下设置起apt-get并运行它，只要把文件/etc/apt/sources.list指向最近的Debian镜像站点就行了（在默认情况下，它指向Debian的主发布站点）。在其他发行版本上不一定有这种集成方式，您或许要建立自己的发布库，对apt-get做些手脚，让它在机构内正确工作。不过，如果您只想要实现自己的本地软件包发布机制，apt-get和apt-rpm都能做很多事儿。
在Debian系统上使用apt-get（以及实际上Debian软件包的所有管理工作）的第一条原则就是忽略dselect的存在，它充当了这一系统的前端它充当了Debian软件包系统的前端。虽然它并不是个坏想法，只是用户界面做得太差了但是用户界面做得太差了。Debian的文档将会试着指导您使用dselect，但您自己要挺住。
如果您采用apt-get来管理从标准Debian镜像站点做的Debian或者Ubuntu安装，要看看能得到什么软件包，最简单的办法就是访问packages.debian.org或者packages.ubuntu.com这两个这个站点。这个站点也提供了一个很有用的搜索界面两种发行版本都提供了一个很有用的搜索界面。如果建立了自己的apt-get服务器，那么您当然会知道能得到什么软件包，也能以您愿意的任何方式提供一份清单也能以您愿意的任何方式把它们给列出来。
Debian各种发行版本一般都包含提供了几个空的软件包（大多数名字以task-开头），之所以存在这样的软件包，只是为了把其他软件包当作前提条件列出。因为apt-get会根据需要，自动下载和升级作为前提的软件包，所以像task-*这样的软件包就能很容易地把几个软件包当作一个整体来安装或者升级。例如，安装gnome-desktop-environmenttask-gnome-desktop这个软件包就会保证您获得安装和有了运行GNOME用户界面所需的全部软件包。
一旦您已经建好了自己的sources.list文件，而且知道您想要的软件包的名字，剩下来的唯一任务就是运行apt-get update来刷新apt-get缓存的软件包信息。在那之后，只需运行apt-get install package-name来安装软件包就行了。同样的命令也会更新已经安装过的软件包。
...
假定我们想要安装sudo软件的一个新版本来修正一个安全bug。首先，执行一次apt-get update总是比较明智的：
现在我们实际上可以获取软件包了。注意，我们在我们获取新的sudo软件包的同时也正在使用sudo—apt-get甚至能在软件仍在使用的时候升级它们！
现在我们实际上可以获取软件包了。注意，我们在我们获取新的sudo软件包的同时也正在使用sudo——apt-get甚至能在软件仍在使用之中的时候升级它们！
我们做完了！还有比这更容易的吗？
2311.64.1
4 配置apt-get
配置apt-get相当直观易懂，它是不时会有缺点的Debian文档中介绍得还不错的地方，需要您了解的每样东西都可以在APT HOWTO里找到：
http://www.debian.org/doc/manuals/apt-howto。
apt-get最重要的配置文件是/etc/apt/sources.list，它告诉apt-get到哪儿去找它的软件包。这个文件里每行规定的内容如下：
— 软件包的类型，目前Debian类型的软件包用deb或者deb-src，RPM用rpm或者rpm-src；
— 指向一个文件、CD-ROM、HTTP服务器或者FTP服务器的URL，从那里可以能够取得软件包；
— “发布（实际上是一个发布的名字）”，能让您提供软件包的多个版本。发行版本提供方使用这个字段来给自己的发行版本指定版本，但是您也可以将它用于您的内部发行系统；
— 组件可能的清单—其实是发行版本内的软件包分类。
除非想要建立自己的API库或者缓存，否则默认配置一般就够用了。如果您有一条比较好的网络连接，那么应该注释掉用来指定Debian安装光盘的那些行。如果您想要下载源代码，就不要注释掉指定deb-src或者rpm-src的那些行。apt-get最重要的配置文件是/etc/apt/sources.list，它告诉apt-get到哪儿去找它的软件包。文件里的每一行都列出了下面的内容：软件包的类型，目前只能是deb或者deb-src；指向一个文件、CD-ROM、HTTP服务器或者FTP服务器的URL，从那里可以能够取得软件包；“发布（distribution）”，能让您提供软件包的多个版本（Debian使用这个字段来给它的发行版本指定版本，但是您也可以将它用于您的内部版本）；以及组件可能的清单——其实是发行版本内的软件包分类。
除非想要建立自己的API库或者缓存，否则默认配置一般就够用了。如果您有一条网络链接，那么或许会注释掉用来指定Debian安装光盘的那些行。如果您想要下载源代码，就取消指定deb-src的那些行的注释。只要您正好在编辑这个文件，就应该把Debian镜像的标识改为离您的最近的一个，在下面的地址可以找到完整的Debian镜像列表：http://www.debian.org/misc/README.mirrors。
|
|
Ubuntu在wiki.ubuntu.com/Archive维护了一个类似的列表。 |
Ubuntu maintains a
similar list at wiki.ubuntu.com/Archive.
要让事情异乎寻常地简单要让事情更简单，Debian提供了一个叫做netselect-apt的工具，它自动会替您生成一个sources.list文件，它根据ping的时间，选择它能找到的最近的映像站点。netselect-apt是netselect软件包的一部分，您可以从离您最近的Debian镜像站点得到它（现成的netselect-apt或多或少和Debian的镜像系统有联系，但是大多数软件包也能在Ubuntu上用，没有问题）。
您也应该确保把security.debian.org或者security.ubuntu.com作为一个来源列出，以便您能访问到最新的安全补丁。
2311.64.2
5 /etc/apt/sources.list文件的例子
下面的例子不但将http.us.debian.org用于稳定的存档文件，而且加入non-us.debian.org作为美国之外使用的软件包（不能从美国出口的加密软件，以前很重要，现在已经没那么重要了）的来源。我们已经加上了security.debian.org，它是所有安全补丁的来源，还加上了我们本地的APT服务器local-debian-serverdebserver。最后，我们打开了下载源代码的功能。
这个例子使用的是稳定的软件库。在实际中间，稳定的Debian发行版本没有别的发行版本那么频繁地变化发布。所有最新的软件包都包含在Debian最新但尚不完善的不稳定（unstable）发行版本中。“不稳定”未必意味着软件包自身不稳定，而是整个发行版本的组成不稳定。每周更新的软件量一般超过100MB。
如果您需要来自测试或者不稳定发行版本的软件包，只要复制那些有stable的行，用unstable（或者testing）替换stable就行了。配置行是按顺序来读取的，所以把unstable和testing行放在文件的末尾，就让stable的版本有了优先权。
sources.list文件里的配置行按顺序逐行分析，所以从理论上说，您可以把unstable和testing行放在文件末尾，让stable（稳定）版本优先。这个方法的问题是，因为APT的依赖性延伸，一个不稳定的软件包会把它所依赖的所有软件包的不稳定更新版本都带进来。这些软件包接下来又可能会把自己所关联软件的不稳定版本再带进来，以此类推。一个老鼠坏了一锅汤，不要在您的生产系统上安装不稳定的软件包。
如果您必须把一个从unstable（不稳定）发行版本来的软件包加到您的生产环境中，正确的做法是使用一个“向后移植（backport）”的软件，即在稳定发布上重新编译它，让它同稳定的库链接。为了找到这些backport和其他细节，可检查位于www.apt-get.org的APT搜索引擎。在Norbert Tretkowski的站点www.backports.org上，能够找到许多向后移植的软件包（不只是给出链接）。在这个软件库中的向后移植软件包质量都很高，对外部的依赖性也最低。
2311.64.3
6 使用代理扩展apt-get
如果您打算在大量主机上使用apt-get，或者想要把软件包缓存在本地—为每台机器都下载每个软件包的一个副本对带宽的使用来说并不划算。您可能也需要指示apt-get通过代理下载软件包，如果防火墙要求有这层保护作用的话。既然apt-get用的就是普通HTTP和FTP协议，所以您可以使用任何碰巧已经装好的web代理。apt-get认可环境变量http_proxy；同样可以在文件/etc/apt/apt.conf里显式地设置代理：
既然apt-get用的就是普通HTTP和FTP协议，所以您可以使用任何碰巧已经装好的Web代理。apt-get认可环境变量http_proxy，同样可以在文件/etc/apt/apt.conf里显式地设置代理：
Acquire::http::Proxy "http://proxyserver:8080/
替代普通Web代理的一种方法是采用一个叫做apt-proxy的小程序。虽然它的名字叫代理，但是却不是一个真正的代理，而只是一个程序，从真正的APT服务器那里用rsync得到软件包，建立它们的缓存。apt-proxy可以从下面的地址得到：http://sourceforge.net/projects/apt-proxy。
2311.64.4
7 设置内部APT服务器
除了使用代理，也可以建立您自己管理的APT服务器，并且把内部的客户机都指向它。这种模式能让您调整向客户机提供的软件包、轻而易举地以推的方式进行升级（只在服务器上安装新版本）、把自己的应用作为软件包来发布，而且最重要的是，提供自己的发行版本。
既然apt-get使用标准的协议（HTTP和FTP）下载它的软件包，建立一台APT服务器所要做的全部工作就是建立一个Web或者FTP服务器，提供适当的内容[7]。建立一台NFS服务器，或者把一张CD-ROM光盘到处传给各台机器也是可行的；apt-get非常灵活。既然与HTTP相关的代理和防火墙得到了广泛的支持服务器和工具得到了广泛的使用，所以HTTP可能是配合APT使用的最简单的协议使用的最方便的协议。21.2.3节里给出了建立Apache Web服务器的指导。
服务器上的软件包可以都放在要把一台普通的HTTP服务器转变为一台APT服务器，需要做的全部工作就是建立一个目录，里面包含软件包。这些软件包可以在一个目录里，或者它们也可以像Debian和Ubuntu的镜像站点那样分布在一个层次型目录结构层次里。
除了提供软件包的文件之外，还必须生成两个软件包的汇总文件：Packages.gz和Contents.gz。前者是服务器上软件包及其依赖关系的清单，并且用gzip压缩过了。apt-get update使用这个清单来确定能够获得哪些补充的软件包。后者建立原始文件到包含它们的软件包的映射关系，apt-get本身实际上并不会用到这个文件。apt-utils这个软件包中包含的apt-ftparchive命令会自动替您生成这两个汇总文件。
apt-utils这个软件包中包含的apt-ftparchive命令会自动生成这两个汇总文件。一旦已经创建好了汇总文件，剩下来的工作就很容易了。在客户机上的/etc/apt/sources.list文件中像下面这样的一行会把apt-get连到您的本地服务器上。
deb http://local-server/mypackages/ ./
在每台客户机上运行apt-get update，然后照常使用apt-get。
如果既要发布源代码，也要发布二进制软件包，只要把源代码软件包放到服务器上即可。Debian发布的源代码有3个部分：普通的.tar.gz文件、一个可选的.diff.gz文件（供软件包维护程序用于显示它们相对于代码原有版本所发生的变化供软件包维护程序去显示它们相对于代码原有版本所发生的变化）、一个.dsc文件（其中包含软件包的说明），这是和RPM不一样的，RPM有一个对等的SRPM，作为源代码软件包。与Packages.gz等价的源代码是Sources.gz，它也是由apt-ftparchive生成的。
前面sources.list文件的例子里没有指定“发布（distribution）”参数。如果您想要用自己的发行版本的名字，从而容许有内部的版本作为内部制订版本的形式，就把每个版本放入一个子目录，把sources.list文件中的./改为版本名或者版本号。制订版本的能力非常有用；有可能有不同的“test（测试）”和“production（生产）”发布，而它们只是指向实际版本的符号链接。您可能想要维护一些测试机器，它们指向了您的“test（测试）”发布。当您对这个版本感到满意时，就可以通过把“production（生产）”的符号链接到新版本上来升级工作主机。
类比Debian自己的“stable”和“testing”发布来创建通称的发行版本，比如“test”和“production”，这种做法往往用处不小。您可以在服务器上用符号链接，把这些名字指向特定的发布，以后只要改变链接的目标目录，就能重新规定发布的内容。例如，当您对一个test（测试）发布感到满意，觉得它能部署它了，就可以把“production（生产）”的符号链接指到同一个目录。客户机把自己与production（生产）发布进行同步，自动获得变更数据。
2311.46.5
8 自动执行apt-get
您可以从cron定期执行apt-get。即使您并不打算自动安装软件包，也可能想要定期执行apt-get update来保持包汇总信息得到更新。
apt-get dist-upgrade会下载并安装已经在本地机器上安装过的任何软件包的新版本。dist-upgrade类似于upgrade，但是在处理依赖关系上稍微聪明一点儿。dist-upgrade可能想要删除它认为和更新过的系统不兼容且解决不了的一些软件包，所以要对可能出现意想不到的结果有所准备。
如果您真的想要冒险，那么就让机器自动执行这项升级—使用-yes选项，这样就无需人来干预操作，它将对apt-get可能回答的任何确认性问题都热诚地回答说“Yes（是）！”。
直接从Debian发行版本的镜像站点执行自动升级操作或许并不是个好主意。不过，如果您有了自己的APT服务器、软件包和发布控制系统，那么这就是保持客户机同步的妥善方式。像下面这样的一个简短的shell脚本能够让一台机器保持和它的APT服务器同步更新。
#!/bin/sh
apt-get update
apt-get -yes dist-upgrade
如果想要在夜间运行这个脚本，就从cron来调用它。您还可以在一个系统启动脚本中调用它，来让机器在引导时更新。参考第98章了解有关cron的更多知识，参考第2章了解有关启动脚本的更多信息。
如果您在许多机器上从croncron里执行更新，那么应该让时间岔开，以确保每次不会让每台机器都更新。1817.2.3节末尾给出的简短的Perl脚本就能帮助完成这项任务。
如果不能完全信任软件包的来源，那么就考虑采用自动下载所有改动过的软件包，但并不安装它们这种方式。用apt-get的--download-only选项来达到这种效果，然后手工复查软件包，并且安装您想要更新的软件包。下载的软件包都保存在/var/cache/apt里，随着时间的推移，这个目录会变得相当大。用apt-get autoclean命令可以从这个目录中清理掉没有用的文件。
如果您使用了一个正规设计的稳定的Debian发行版本，那么我们将毫无保留地建议您采用自动更新。稳定发行版本中的变化一般限制在安全更新上，而且完整性测试做得很好。唯一可能发生的问题是您或许在一个新的主发布出现的时候不想自动升级。为了避免发生这样的问题，可以在sources.list文件里明确指定发行版本的名字而不是stable这个关键字。
11.4.9 yum：管理RPM的发布
yum（Yellowdog Updater，Modified）是基于RPM的元软件包管理器[8]。把yum叫做apt-get的克隆可能有一点儿不公平，但是它从提法上和实现上都类似于apt-get，只是实际上用起来更简洁和速度更慢。yum是Fedora的正式软件包管理系统，在许多别的发行版本上也预装了它。如果有必要，您可以从linux.duke.edu/yum获得它的最新版本。
和apt-get一样，服务器端的命令（yum-arch）汇编了一个数据库，其中是大量软件包（往往是一个发布中的软件包）的头信息。然后通过HTTP或者FTP把头信息数据库随软件包一起对外共享。客户机使用yum命令推断出依赖性限制，然后完成安装所需软件包要求的其他任何工作。如果要安装的软件包依赖别的软件包，那么yum也会下载并安装那些软件包。
apt-get和yum之间的相似性也扩大到了它们所支持的命令行参数上