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
