6.7. 升级至下个稳定发行版

Debian 知名的功能之一是可升级至下个稳定版:dist-upgrade — 知名的句子 — 相当促进 Debian 的名声。除了极少的例外，升级电脑系统只需几分钟的时间，或暂十来分钟，依照从软件包保存库下载的速度而定.

6.7.1. 建议进程

Debian 各稳定版之间存在相当的差异，升级前应仔细阅读发布说明。

基本 发布说明

操作系统 (更宽广的说，任何软件都在内) 的发布说明是一份描述软件概况的文档，特别关照指定的版本。相对于完成的软件文档，这些文档相当简短，通常列出前版之后新生成的功能。也提供升级的进程、对前版用户的警示、以及若干错误更正。

Release notes are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/stretch/releasenotes

In this section, we will focus on upgrading a Stretch system to Buster. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

减少安装的软件包，只安装绝对必要的软件包，才能让升级容易 (且简短)。相关的工具包括 aptitude、deborphan 与 debfoster (见 第 6.2.7 节 “自动追踪已安装的软件包”)。例如，您可使用以下命令，再使用 aptitude 的交互模式再检查并微调该移除的软件包：

  1. # deborphan | xargs aptitude --schedule-only remove

TIP Finding changed files

The debsums command can check if files on the local system, which are part of an installed package, have been altered. It uses a simple hashsum algorithm and the information in /var/lib/dpkg/info/*package*.md5sums (see 第 5.2.3 节 “校验，配置文件列表”). To find all altered configuration files use debsums -ec. To check the whole system, use debsums -c.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Buster instead of Stretch. If the file only contains references to Stable rather than explicit codenames, the change isn’t even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed (with the apt update command or the refresh button in synaptic).

NOTE Repository information changes

When a new stable version of Debian is released, some fields in the Release and InRelease files of a repository change, like the Suite field. When this happens, downloading data from the repository is declined until the change is confirmed to ensure the user is prepared for it. To confirm the change use the --allow-releaseinfo-change or --allow-releaseinfo-change-*field* options for apt-get or the Acquire::AllowReleaseInfoChange configuration option.

注册这些添加的软件包来源后，首先运行最低量的升级 apt upgrade。以两阶段升级，减缓软件包管理工具的工作并确保使用最新的软件包，纳入完整发行版升级所需的错误更正与改进。

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic. You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Buster system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.7.2. 处理升级后的问题

仅管 Debian 管理者已经尽力做好份内的工作，主系统的升级仍可能卡卡的不如想像中顺利。软件的新版本可能无法与旧的兼容 (例如，可能改变缺省行为或数据格式)。同时，尽管在 Debian 发布前做为详尽的测试，还是有若干漏网的错误。

可以先安装 apt-listchanges package, 软件包，在软件包升级前先显示可能问题。由软件包维护者编辑的这些信息且置于 /usr/share/doc/*软件包名*/NEWS.Debian 文件名内，供用户参考。阅读该等文件 (可能经由 apt-listchanges) 应有助于归避不好的意外。

You might sometimes find that the new version of a software doesn’t work at all. This generally happens if the application isn’t particularly popular and hasn’t been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/*package*, and check whether the problem has already been reported. If this is case it will be also listed before the upgrade begins, if you have apt-listbugs installed. If it hasn’t, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

  • 有时已有补丁，并且列在错误报告内；可以本地重新编译修补破碎的软件包 (见 第 15.1 节 “从源码重建安装包”);

  • 否则，用户可能找到另个解决问题的方法且在报告内分享;

  • 再不然，维护者可能已准备并公开修订软件包。

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see 第 6.1.2.3 节 “计划更新”). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

Sometimes the fixed package isn’t available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren’t available yet, but at least you know that the publication process is ongoing.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Cleaning Up after an Upgrade

APT usually ensures a clean upgrade, pulling in new and updated dependencies, or removing conflicting packages. But even being such a great tool, it cannot cover all tasks users and administrators will face after an upgrade, because they require a human decision.

6.7.3.1. Packages removed from the Debian Archive

Sometimes the Debian FTP Masters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

  1. $

A similar result can be achieved by aptitude search ~o. If the packages found are not required anymore, they should be purged from the system, because they will not face any updates for critical or security related bugs anymore.

6.7.3.2. Dummy and Transitional Packages

Sometimes, it might be necessary for a package to get a new name. In this case often the old package is kept as an (almost) empty package, depending on the new one and installing only the mandatory files in /usr/share/doc/*package*/. Such packages are called “dummy” or “transitional” packages. If the package maintainer in charge also changed the section of this package to oldlibs, then tools like aptitude, deboprhan, or debfoster (see sidebar 其他 deborphan 与 debfoster) can pickup these packages to suggest their removal.

Unfortunately there is currently no foolproof way of making sure that these packages are automatically removed or picked by the tools mentioned above. One way to check if the system still has some of these packages installed, is to look through the package descriptions of installed packages and then check the results. Be careful not to schedule the results for automatic removal, because this method can lead to false positives:

  1. $

Because the new package is pulled in as a dependency of the transitional package, it is usually marked as automatically installed and might be scheduled for removal if you try to purge the transitional package from your system. In this case you can use either of the approaches described in sidebar TIP 同时进行卸载和安装 and 第 6.2.7 节 “自动追踪已安装的软件包” to selectively remove the transitional package.

6.7.3.3. Old or Unused Configuration Files

If the upgrade was successful there might be some configuration file cruft, either from dpkg (see 第 5.2.3 节 “校验，配置文件列表”), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files, that were handled by dpkg or ucf during the upgrade process, have left some counterparts with a dedicated suffix (e.g. .dpkg-dist, .dpkg-old, .ucf-old). Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

6.7.3.4. Files not owned by any Package

The Debian policy enforces that packages don’t leave files behind when they are purged. Violating this principle is a serious bug and you will rarely encounter it. If you do, report it; and if you are curious though, you can use the cruft or cruft-ng package to check your system for files not owned by any package.