Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Julian Andres Klode, le mar. 15 déc. 2020 16:15:23 +0100, a ecrit:
> > 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
Reply to: