The problem is that these are not equivalent: apt upgrade will attempt
to install additional packages required by newer versions of existing
packages. That can lead to conflicts/breaks with other existing
packages, and thus get into all the complexity that using apt-get
upgrade first avoids.
You mean that using apt upgrade upgrades more packages already, and
hence dist-upgrade has less conflicts?
No, I mean that apt upgrade will encounter more conflicts by trying to
install newer packages, which may break/conflict other old packages.
:D You can argue that in circles, you don't know which is going to be
better.
Whatever is "best" or "worse", what we want is that what users actually
use is what is documented and *tested*. If we fail that we'll continue
seeing users getting trapped into conflicts etc.
Of course people are free to apt upgrade --without-new-pkgs. The
optimal way to upgrade likely is
apt upgrade --without-new-pkgs
apt upgrade
apt full-upgrade
which is equivalent to
apt-get upgrade
apt-get upgrade --with-new-pkgs
apt-get dist-upgrade
Will the second step nicely behave in the case of a new package that
conflicts/breaks with an old already-installed package?
The problem is then that actual users end up in *other* situations than
what would typically be tested according to the release notes.
People should test apt for interactive systems, and apt-get for
non-interactive systems, as always.
I believe few developpers know this, and have their hands used to
apt-get, not apt. As shown by the release notes which document using
apt-get, not apt.
Enabling progress for apt-get - the legacy scripting frontend -
is a no-go. As is removing it from apt - the interactive user's
frontend.
So we'd rather make release-notes document using apt instead of
apt-get? I'm fine with that but we *ALSO* need to make sure that debian
developers actually *test* that path, and not the apt-get path.
Samuel