یکی از بهترین ویژگیهای دبیان قابلیت بروزرسانی کلی آن از یک توزیع پایدار به انتشار بعدی است: dist-upgrade -- عبارتی با معنا -- اعتبار زیادی را برای این پروژه به ارمغان آورده است. با رعایت برخی پیشزمینهها، بروزرسانی یک رایانه تنها چند دقیقه زمان نمیبرد که آن نیز بسته به سرعت دانلود بستهها از اینترنت متفاوت است.
از آنجایی که زمان نسبتا زیادی بین دو نسخه پایدار دبیان فاصله میافتد، قبل از بروزرسانی کلی باید یادداشت انتشار آن را مطالعه کنید.
In this section, we will focus on upgrading a Bullseye system to Bookworm. 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.
Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include
aptitude
,
deborphan
,
debfoster
, and
apt-show-versions
(see
قسمت 6.2.7, “ردیابی خودکار بستههای نصب شده”
). For example, you can use the following command, and then use
aptitude
's interactive mode to double check and fine-tune the scheduled removals:
#
deborphan | xargs aptitude --schedule-only remove
Now for the upgrading itself. First, you need to change the
/etc/apt/sources.list
file to tell APT to get its packages from
Bookworm instead of
Bullseye. 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
(
قسمت 6.2.1, “راهاندازی”
).
Once these new package sources are registered, you should first do a minimal upgrade with
apt upgrade
et al. as described in
قسمت 6.2.3, “بروزرسانی سیستم”
. By doing the upgrade in two steps, we ease the job of the package management tools and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade.
Once this first upgrade is done, it is time to handle the upgrade itself, either with
apt full-upgrade
,
aptitude
, or
synaptic
(
قسمت 6.7, “بروزرسانی کلی از یک توزیع پایدار به دیگری”
). 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 frontend should come up with a scenario ending in a coherent and up-to-date
Bookworm 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. بررسی مشکلات پس از بروزرسانی کلی
با تمام تلاشهای صورت گرفته، یک بروزرسانی کلی ممکن است همیشه خوب پیش نرود. نسخههای جدید نرمافزار ممکن است با نسخههای پیشین ناسازگار باشند (برای نمونه، رفتار پیشفرض آنها یا قالب دادهیشان ممکن است تغییر کند). برخی باگها ممکن است از دید فرآیند تست که همیشه قبل از انتشار دبیان صورت میگیرد، مخفی مانده باشند.
برای پیشبینی این مشکلات، میتوانید بسته apt-listchanges را نصب کنید که احتمال بروز مشکلات در ابتدای فرآیند بروزرسانی کلی را بررسی میکند. این اطلاعات توسط نگهدارندههای بسته کامپایل شده و در فایل /usr/share/doc/package/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:
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.
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 ftpmasters 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:
$
apt-show-versions | grep "No available version"
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:
$
dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"
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
نکته نصب و حذف در یک زمان 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, “Checksums, List of Configuration Files, et al.”
), 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.
Be aware that a purge also removes the data created with a particular package (e.g. database files, docker volumes and containers, etc.). There should always be backups in place in case data gets removed accidentally.
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.