[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: