1. upgrade-advisor DebConf9 Caceres, Extremadura, Spain Frank lin Piat 2009-07-26

2. Introduction (1/2) The Debian project provides some tools to assist users installing new systems (Debian Installer...) When a new stable is released, users want to upgrade their existing systems. dpkg and APT provides all the infrastructure to upgrade the systems (pre/post-install/rm scripts)

3. Introduction (2/2) ● Each package can contain a file to document important changes. /usr/share/doc/$package/NEWS.Debian(.gz) ● Each package can print message during upgrade (and even automatically fix problems). ● The Release-Notes contains important upgrade notes.

4. What's the problem?

5. Upgrading a stable distribution ● Known upgrade issues ● Major changes, discontinued features, problematic configuration, incompatibilities... ● Local system (re)-configuration ● User have configured the software in a specific way. ● New default behavior ● New version of a software have a new default behavior. Debian use a new default $foo program... ● One can only read the NEWS.Debian once the new package is installed (actually, once sources.list is upgraded)

6. What's needed?

7. Some predictability (plan & prepare)

8. Solution (from a user perspective) From the user's point, there are three stages: 1.Before the upgrade : Plan and prepare ➢ RTFM ➢ Run “ upgrade-advisor pre-upgrade” 2.During the upgrade (note: this is mainly handled by the dpkg and APT frameworks) 3.After the upgrade : Align with fresh installation ➢ RTFM ➢ Run “ upgrade-advisor post-upgrade”

9. upgrade-advisor Upgrade-advisor focus on two stages ● pre-upgrade ● post-upgrade

10. Example: pre-upgrade (see etch.human.txt and etch.machine.txt)

11. Example: post-upgrade (usually similar)

12. Conventions used “n” → the currently installed distribution “n+1” → target version, we want to upgrade to. “n-1” → previous distribution (former upgrade) Reminder: Debian only supports upgrading from one version to another (i.e one should not skip a version).

13. pre-upgrade (1/3) 1. Previous upgrade tasks from n-1 to n (ensure that “post installation steps” were performed). Examples: ● Path to $foo-bin has changed in etch, but symlink was provided for transition. ● Configuration file for $foo was renamed, but the old file was still parsed.

14. pre-upgrade (2/3) 2. Check the state of the current system Example: ● State of the packages (orphan, broken...) check_orphan_packages ● List of packages sources (mixed distribution, pinning, etc.) check_apt_sources ● Bootloader (will the system boot off it's new kernel, etc...)

15. pre-upgrade (3/3) 3. Test for known issues, upgrading n to n+1 ● Discontinued packages (or becoming non-free) ● Discontinued hardware support (wishlist feature) ● Packages requiring substantial manual reconfiguration and/or migration. (priority in NEWS.Debian?)

16. post-upgrade (1/2) 2. Check the state of the current system Example: ● State of the packages (orphan, broken...) ● List of packages sources (mixed distribution, pinning, etc.) ● Bootloader (will the system boot off it's new kernel, etc...)

17. post-upgrade (2/2) 1. Ensure that “post installation steps” were performed. Examples: ● Path to $foo has changed in etch, but symlink was provided for transition. ● Configuration file for $foo was renamed, but the old file was still parsed.

18. Writing a plug-in File plugins/A-20_check_update_grub_path ------------------------------------------------------------------------ #!/bin/sh check_update_grub_path() { [ $CURRENT_OS -lt $ETCH ] && return 0 title "Checking update-grub path in kernel-img.conf" if grep -E "[[:blank:]=]+/sbin/update-grub" /etc/kernel-img.conf > /dev/null 2>&1; then gecho "The path to update-grub in /etc/kernel-img.conf is wrong." | alert gecho "$RELNOTES/ch-upgrading.en.html#s-for_next" | extra fi }ch-upgrading.en.html#s-for_next ------------------------------------------------------------------------

19. Guidelines for writing a plugin ● The script must pure bourne-shell (/bin/sh) script. i.e. No bashism! ● The plugins are first sourced by the main script, then the mainfunction of each are called. ● The main function of the script must be name after the filename. ● The main function should start with : ● title "My plugin Description." ● The correct way to print a message is to use something like gecho "This is a test" | warn ● The command gecho is a wrapper for gettext. ● "warn (or info, extra, verbose, error) are pipes to pretty print the error messages, by prefixing with "I: ". "error" is used only to denote that the _test_ can't be run. ● If your plugin only apply, starting at a given distribution, you can start the function with something like: [ $CURRENT_OS -lt $ETCH ] && return 0 ● Try to not depend on any tool, but the core (essential) ones. ● If a tool is missing, you should warn that the test is skipped and explain why.

20. Contributions Homepage http://wiki.debian.org/UpgradeAdvisor Git repository git clone git://git.debian.org/git/collab-maint/upgrade-advisor.git

21. Questions? Comments?

22. Thank you.