Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Hello, Paul Gevers, le jeu. 18 mars 2021 12:01:33 +0100, a ecrit: > On 17-03-2021 19:40, Samuel Thibault wrote: > > Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit: > >>> "apt upgrade --without-new-pkgs" > >> > >> Looking into history, I see we did this because of > >> https://bugs.debian.org/931637. I guess your suggestion is a better > >> alternative? > > > > It would probably fill both the objective of upgrading without new > > packages, and letting users have a progression bar, yes. > > Sanity check, does the attached patch do what you mean? Yes! Samuel
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Hi Samuel, all On 17-03-2021 19:40, Samuel Thibault wrote: > Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit: >>> "apt upgrade --without-new-pkgs" >> >> Looking into history, I see we did this because of >> https://bugs.debian.org/931637. I guess your suggestion is a better >> alternative? > > It would probably fill both the objective of upgrading without new > packages, and letting users have a progression bar, yes. Sanity check, does the attached patch do what you mean? (I put Samuel as the author, to give the credits). Paul From baef5aa4289ee025751391601200939c6e7482df Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Thu, 18 Mar 2021 11:59:14 +0100 Subject: [PATCH] en/upgrading.dbk: also use apt (but with options) during minimal upgrade Closes: #977477 --- en/upgrading.dbk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/en/upgrading.dbk b/en/upgrading.dbk index 4fab1c40..da12d99d 100644 --- a/en/upgrading.dbk +++ b/en/upgrading.dbk @@ -969,7 +969,7 @@ E: You don't have enough free space in /var/cache/apt/archives/. To do this, first run: -# apt-get upgrade +# apt upgrade --without-new-pkgs This has the effect of upgrading those packages which can be upgraded without -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit: > > "apt upgrade --without-new-pkgs" > > Looking into history, I see we did this because of > https://bugs.debian.org/931637. I guess your suggestion is a better > alternative? It would probably fill both the objective of upgrading without new packages, and letting users have a progression bar, yes. Samuel
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Hi Samuel On 16-03-2021 22:17, Samuel Thibault wrote: > Paul Gevers, le mar. 16 mars 2021 22:08:51 +0100, a ecrit: >> wrote: >>> 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. >> >> Already the buster release notes talk about using apt instead of apt-get > > Mmm, actually no, it tells to use "apt-get upgrade" > > https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade > > Possibly this should be turned to > > "apt upgrade --without-new-pkgs" > > ? Looking into history, I see we did this because of https://bugs.debian.org/931637. I guess your suggestion is a better alternative? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Paul Gevers, le mar. 16 mars 2021 22:08:51 +0100, a ecrit: > wrote: > > 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. > > Already the buster release notes talk about using apt instead of apt-get Mmm, actually no, it tells to use "apt-get upgrade" https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade Possibly this should be turned to "apt upgrade --without-new-pkgs" ? Otherwise people will continue replacing apt-get with apt in "apt-get upgrade" without knowing that they are really different, and get upgrading bugs that maintainers that use "apt-get upgrade" (expectedly) do not get. > and even has a note about the difference [1]. I'm not aware (but I don't > follow user facing help channels) that this has lead to problems that > would have been prevented with sticking to apt-get. I did see some users getting upgrading issues when running "apt upgrade", while "apt-get upgrade" first would have solved them. Samuel
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Control: tags -1 moreinfo Hi Samuel, On Tue, 15 Dec 2020 16:27:35 +0100 Samuel Thibault wrote: > 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. Already the buster release notes talk about using apt instead of apt-get and even has a note about the difference [1]. I'm not aware (but I don't follow user facing help channels) that this has lead to problems that would have been prevented with sticking to apt-get. I agree apt should be tested, but I don't know how to fix that. What do you propose we change in the release notes? Paul [1] https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#upgradingpackages OpenPGP_signature Description: OpenPGP digital signature
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
Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)
Control: reassign -1 release-notes Control: retitle -1 release-notes: Update apt upgrade guidance On Tue, Dec 15, 2020 at 03:40:55PM +0100, Samuel Thibault wrote: > Package: apt > Version: 2.1.12 > Severity: normal > > Hello, > > The release notes tell people that they should basically use > > apt-get upgrade > apt-get dist-upgrade > > But people tend to rather use > > apt upgrade > apt dist-upgrade > 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? :D You can argue that in circles, you don't know which is going to be better. 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 > > 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. Enabling progress for apt-get - the legacy scripting frontend - is a no-go. As is removing it from apt - the interactive user's frontend. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#977477: apt: Adding progression indication to apt-get output
I forgot to mention: yes, the addition of number in the package name provides some indication, but that is too small for people to notice or find it usable. Samuel
Bug#977477: apt: Adding progression indication to apt-get output
Package: apt Version: 2.1.12 Severity: normal Hello, The release notes tell people that they should basically use apt-get upgrade apt-get dist-upgrade But people tend to rather use apt upgrade apt dist-upgrade I guess essentially because apt provides progression indication. 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. The problem is then that actual users end up in *other* situations than what would typically be tested according to the release notes. We can try to insist on making people use apt-get upgrade instead of apt upgrade, but I believe that can only work if apt-get provides at least *some* progress indication, especially for distribution upgrades, whose duration are quite unknown before doing them. Alternatively, we could fix apt into behaving really like apt-get, to avoid that discrepancy between what debian developers actually test and what users actually use. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.20-1 ii gpgv1 1.4.23-1+b1 ii libapt-pkg6.0 2.1.12 ii libc6 2.31-5 ii libgcc-s1 10.2.1-1 ii libgnutls30 3.6.15-4 ii libseccomp2 2.5.0-3+b1 ii libstdc++6 10.2.1-1 ii libsystemd0 247.1-3 Versions of packages apt recommends: ii ca-certificates 20200601 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.13-2+b1 ii dpkg-dev1.20.5 ii gnupg 2.2.20-1 ii gnupg1 1.4.23-1+b1 ii gnupg2 2.2.20-1 ii powermgmt-base 1.36 ii synaptic0.90.2 -- no debconf information