Zimbra Forums

Just did as described and everything went fine.

A simple `apt-get update && apt-get upgrade` should be enough. And that should be pretty safe. Actually, never had any serious trouble with that, as the usual policy @ubuntu (same w/ Debian) only does _minor_ bugfix/security upgrades (within a release) - they usually dont upgrade to newer (major) upstream releases. That's why `unattended-upgrades` should be the preferred way.



(yes, in fact, I already had some problems that way, but just on some freedesktop stuff, eg. polkit, etc, which is buggy and broken-by-design anyways - completely irrelevant for server stuff)



By the way: dist-upgrade is only needed, if some packages are held back. And that usually only happens when the upgrade introduces some new dependencies, which aren't installed yet (IOW: the selected-packages-set changes).

Dont mix it up w/ `do-release-upgrade`, which actually moves to a new distro release (thus upgrading to really new (major) versions).

> don't do a dist-upgrade, you will upgrade your entire Ubuntu to the next version, 10 to 12, 12 to 14.



No, what you're talking about is `do-release-upgrade`. (at least for Ubuntu)

The dist-upgrade is only needed if the package set changes, eg. because an upgrade would pull in new dependencies.

Hi metux,
You have right, sorry I've messed up the concepts - https://help.ubuntu.com/lts/serverguide ... ading.html
And from the man of the apt-get:

dist-upgrade
in addition to performing the function of upgrade,
also intelligently handles changing dependencies with new versions
of packages; apt-get has a "smart" conflict resolution system, and
it will attempt to upgrade the most important packages at the
expense of less important ones if necessary. So, dist-upgrade
command may remove some packages. The /etc/apt/sources.list file
contains a list of locations from which to retrieve desired package
files. See also apt_preferences(5) for a mechanism for overriding
the general settings for individual packages


Best regards and thank you for the note!

No, that's exactly what I've said (just w/ more words): the package set changes.



The reason behind the differenciation between plain upgrade and release-upgrade is that operators might not expect a changing package set (eg. possibly some packages disappearing, or new ones appearing that might cause some trouble). Therefore apt wants to be told explicitly to do such changes.

Originally, dist-upgrade was meant to run a dist release upgrade - *AFTER* sources.list was adapted to the new repo/release name. But some packages aren't upgradable that easily, but need some more magic (well, some upstreams are just dumb :p), that's what do-release-upgrade (and associated per-dist/-release upgrade scripts) is for.

Exactly.



The rationale behind this is that users/operators might actively use certain packages which had been pulled in implicitly via dependencies and could be removed by deps changing on some upgrade. That could lead to some unexpected behaviour (from users/operators PoV - even though logically the system remains consistent), so apt provides an additional line of safety here.



In other words: plain `apt-get upgrade` generally is safe enough to be run automatically (see: unattended-upgrades).

dist-upgrade should be done w/ some bit of caution (on production systems), just to be sure.



OTOH, an full release upgrade, is a different topic, which - for important production systems - should be well-tested.

Thank you metux for the explanation. I'm pretty sure that will help others, and now I have more clear the difference between both commands.



Best regards!