[pacman-dev] "local version is up to date. Upgrade anyway?" question
For testing the last patch from Nagy that makes the "dependency cycle" warning more verbose, I wanted to do : pacman -S base But then cancel the operation. The problem is that, for every package, I got the following question : local version is up to date. Upgrade anyway? I couldn't use --noconfirm , because I didn't want to actually do the operation, only preview it. Also, --noconfirm will answer other questions than this one. Actually, this is exactly the issue that was mentioned in this thread : http://bbs.archlinux.org/viewtopic.php?id=35901 The only way was to use the --ask option, which was too complicated and has been removed. We probably don't need the power of this function anyway. But maybe we could have a replacement, just for this "local version is up to date" question. Or, is this question really useful anyway? How often do we try installing an already installed package, without the intention to reinstall it? Or maybe pacman could just print a warning instead : # pacman -S foo warning : foo is already installed ...
For testing the last patch from Nagy that makes the "dependency cycle" warning more verbose, I wanted to do : pacman -S base But then cancel the operation. The problem is that, for every package, I got the following question : local version is up to date. Upgrade anyway?
I couldn't use --noconfirm , because I didn't want to actually do the operation, only preview it. Also, --noconfirm will answer other questions than this one.
Actually, this is exactly the issue that was mentioned in this thread : http://bbs.archlinux.org/viewtopic.php?id=35901 The only way was to use the --ask option, which was too complicated and has been removed. We probably don't need the power of this function anyway. But maybe we could have a replacement, just for this "local version is up to date" question. Or, is this question really useful anyway? How often do we try installing an already installed package, without the intention to reinstall it?
See also my comments here: http://bugs.archlinux.org/task/8242 Well, I never used the --ask option before, so I don't know what that did. So I may want to (re)implement it.
Or maybe pacman could just print a warning instead : # pacman -S foo warning : foo is already installed ...
This seems OK to me (if in this case foo will be upgraded): atm I cannot find any case when an already-installed package is pulled to target list "automatically". Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Wed, Nov 21, 2007 at 04:02:46PM +0100, Nagy Gabor wrote:
For testing the last patch from Nagy that makes the "dependency cycle" warning more verbose, I wanted to do : pacman -S base But then cancel the operation. The problem is that, for every package, I got the following question : local version is up to date. Upgrade anyway?
I couldn't use --noconfirm , because I didn't want to actually do the operation, only preview it. Also, --noconfirm will answer other questions than this one.
Actually, this is exactly the issue that was mentioned in this thread : http://bbs.archlinux.org/viewtopic.php?id=35901 The only way was to use the --ask option, which was too complicated and has been removed. We probably don't need the power of this function anyway. But maybe we could have a replacement, just for this "local version is up to date" question. Or, is this question really useful anyway? How often do we try installing an already installed package, without the intention to reinstall it?
See also my comments here: http://bugs.archlinux.org/task/8242
Well, I never used the --ask option before, so I don't know what that did. So I may want to (re)implement it.
You can see the above forum thread where I tried to explain it. Or look at the commit where it was removed: http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=1ff8e7f364a9f...
Or maybe pacman could just print a warning instead : # pacman -S foo warning : foo is already installed ...
This seems OK to me (if in this case foo will be upgraded): atm I cannot find any case when an already-installed package is pulled to target list "automatically".
I guess it's mostly useful when you want to check that something is installed. For example, you're following a guide on archwiki and you copy/paste a pacman -S command, because you're not sure which tools are installed. So it looks like the two use cases are possible : 1) reinstalling all the packages 2) only install the missing ones So it seems like in all cases, you want to either answer all the "Upgrade anyway?" questions by yes, or all by no. So maybe yet another option / flag would be better for choosing the answer globally, instead of case by case :p
On Nov 21, 2007 10:33 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Nov 21, 2007 at 04:02:46PM +0100, Nagy Gabor wrote:
For testing the last patch from Nagy that makes the "dependency cycle" warning more verbose, I wanted to do : pacman -S base But then cancel the operation. The problem is that, for every package, I got the following question : local version is up to date. Upgrade anyway?
I couldn't use --noconfirm , because I didn't want to actually do the operation, only preview it. Also, --noconfirm will answer other questions than this one.
Actually, this is exactly the issue that was mentioned in this thread : http://bbs.archlinux.org/viewtopic.php?id=35901 The only way was to use the --ask option, which was too complicated and has been removed. We probably don't need the power of this function anyway. But maybe we could have a replacement, just for this "local version is up to date" question. Or, is this question really useful anyway? How often do we try installing an already installed package, without the intention to reinstall it?
See also my comments here: http://bugs.archlinux.org/task/8242
Well, I never used the --ask option before, so I don't know what that did. So I may want to (re)implement it.
You can see the above forum thread where I tried to explain it. Or look at the commit where it was removed: http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=1ff8e7f364a9f...
Or maybe pacman could just print a warning instead : # pacman -S foo warning : foo is already installed ...
This seems OK to me (if in this case foo will be upgraded): atm I cannot find any case when an already-installed package is pulled to target list "automatically".
I guess it's mostly useful when you want to check that something is installed. For example, you're following a guide on archwiki and you copy/paste a pacman -S command, because you're not sure which tools are installed. So it looks like the two use cases are possible : 1) reinstalling all the packages 2) only install the missing ones
So it seems like in all cases, you want to either answer all the "Upgrade anyway?" questions by yes, or all by no. So maybe yet another option / flag would be better for choosing the answer globally, instead of case by case :p
This seems like the mirror of your --unneeded option, in a way. Not sure if --needed is really the best way to describe it, but it is a possibility. This would also allow us to remove the -F option if we ported it to -U/-A as well. -Dan
On Wed, Nov 21, 2007 at 11:19:25AM -0500, Dan McGee wrote:
This seems like the mirror of your --unneeded option, in a way. Not sure if --needed is really the best way to describe it, but it is a possibility.
Yes, kind of.
This would also allow us to remove the -F option if we ported it to -U/-A as well.
Except that -F apparently doesn't want to install new packages, only upgrade existing but outdated ones. While the option I had in mind for -S would either install new packages, or upgrading existing but outdated ones. But I never used -F once in all the time I used Arch. Who uses this option? I actually was surprised when I first saw it some times ago. And I already forgot it existed, since I never see it mentioned anywhere.
On Wed, Nov 21, 2007 at 05:46:59PM +0100, Xavier wrote:
On Wed, Nov 21, 2007 at 11:19:25AM -0500, Dan McGee wrote:
This seems like the mirror of your --unneeded option, in a way. Not sure if --needed is really the best way to describe it, but it is a possibility.
Yes, kind of.
It's very easy to implement, but I'm still wondering if people will like it :P So here is an example with pacman -S xorg: ** Current behavior (pressing enter at each question for the default answer) : xav@nx7400> sudo pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] :: xf86-input-keyboard-1.2.2-2: local version is up to date. Upgrade anyway? [Y/n] :: xf86-input-mouse-1.2.3-1: local version is up to date. Upgrade anyway? [Y/n] :: xorg-server-1.4-5: local version is up to date. Upgrade anyway? [Y/n] :: xorg-xinit-1.0.7-1: local version is up to date. Upgrade anyway? [Y/n] :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] resolving dependencies... done. looking for inter-conflicts... done. Targets: xf86-input-keyboard-1.2.2-2 xf86-input-mouse-1.2.3-1 xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-server-1.4-5 xorg-twm-1.0.1-2 xorg-xinit-1.0.7-1 xterm-229-2 Total Download Size: 22.89 MB Total Installed Size: 29.84 MB Proceed with installation? [Y/n] ** New behavior: xav@nx7400> sudo src/pacman/pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] warning: xf86-input-keyboard-1.2.2-2 is up to date -- reinstalling warning: xf86-input-mouse-1.2.3-1 is up to date -- reinstalling warning: xorg-server-1.4-5 is up to date -- reinstalling warning: xorg-xinit-1.0.7-1 is up to date -- reinstalling warning: xterm-229-2 is up to date -- reinstalling resolving dependencies... done. looking for inter-conflicts... done. Targets: xf86-input-keyboard-1.2.2-2 xf86-input-mouse-1.2.3-1 xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-server-1.4-5 xorg-twm-1.0.1-2 xorg-xinit-1.0.7-1 xterm-229-2 Total Download Size: 22.89 MB Total Installed Size: 29.84 MB Proceed with installation? [Y/n] ** Current behavior (anwering no to all uptodate questions) : xav@nx7400> sudo pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] :: xf86-input-keyboard-1.2.2-2: local version is up to date. Upgrade anyway? [Y/n] n warning: xf86-input-keyboard-1.2.2-2 is up to date -- skipping :: xf86-input-mouse-1.2.3-1: local version is up to date. Upgrade anyway? [Y/n] n warning: xf86-input-mouse-1.2.3-1 is up to date -- skipping :: xorg-server-1.4-5: local version is up to date. Upgrade anyway? [Y/n] n warning: xorg-server-1.4-5 is up to date -- skipping :: xorg-xinit-1.0.7-1: local version is up to date. Upgrade anyway? [Y/n] n warning: xorg-xinit-1.0.7-1 is up to date -- skipping :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] n warning: xterm-229-2 is up to date -- skipping resolving dependencies... done. looking for inter-conflicts... done. Targets: xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-twm-1.0.1-2 Total Download Size: 22.89 MB Proceed with installation? [Y/n] n ** New behavior with --needed: xav@nx7400> sudo src/pacman/pacman -S --needed xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] warning: xf86-input-keyboard-1.2.2-2 is up to date -- skipping warning: xf86-input-mouse-1.2.3-1 is up to date -- skipping warning: xorg-server-1.4-5 is up to date -- skipping warning: xorg-xinit-1.0.7-1 is up to date -- skipping warning: xterm-229-2 is up to date -- skipping resolving dependencies... done. looking for inter-conflicts... done. Targets: xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-twm-1.0.1-2 Total Download Size: 22.89 MB Proceed with installation? [Y/n]
2007/11/22, Xavier <shiningxc@gmail.com>:
On Wed, Nov 21, 2007 at 05:46:59PM +0100, Xavier wrote:
On Wed, Nov 21, 2007 at 11:19:25AM -0500, Dan McGee wrote:
This seems like the mirror of your --unneeded option, in a way. Not sure if --needed is really the best way to describe it, but it is a possibility.
Yes, kind of.
It's very easy to implement, but I'm still wondering if people will like it :P
[skipped] I like the new behaviour you propose. :-) -- Roman Kyrylych (Роман Кирилич)
Idézés Xavier <shiningxc@gmail.com>:
On Wed, Nov 21, 2007 at 05:46:59PM +0100, Xavier wrote:
On Wed, Nov 21, 2007 at 11:19:25AM -0500, Dan McGee wrote:
This seems like the mirror of your --unneeded option, in a way. Not sure if --needed is really the best way to describe it, but it is a possibility.
Yes, kind of.
It's very easy to implement, but I'm still wondering if people will like it :P
So here is an example with pacman -S xorg:
** Current behavior (pressing enter at each question for the default answer) :
xav@nx7400> sudo pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] :: xf86-input-keyboard-1.2.2-2: local version is up to date. Upgrade anyway? [Y/n] :: xf86-input-mouse-1.2.3-1: local version is up to date. Upgrade anyway? [Y/n] :: xorg-server-1.4-5: local version is up to date. Upgrade anyway? [Y/n] :: xorg-xinit-1.0.7-1: local version is up to date. Upgrade anyway? [Y/n] :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] resolving dependencies... done. looking for inter-conflicts... done.
Targets: xf86-input-keyboard-1.2.2-2 xf86-input-mouse-1.2.3-1 xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-server-1.4-5 xorg-twm-1.0.1-2 xorg-xinit-1.0.7-1 xterm-229-2
Total Download Size: 22.89 MB Total Installed Size: 29.84 MB
Proceed with installation? [Y/n]
** New behavior:
xav@nx7400> sudo src/pacman/pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] warning: xf86-input-keyboard-1.2.2-2 is up to date -- reinstalling warning: xf86-input-mouse-1.2.3-1 is up to date -- reinstalling warning: xorg-server-1.4-5 is up to date -- reinstalling warning: xorg-xinit-1.0.7-1 is up to date -- reinstalling warning: xterm-229-2 is up to date -- reinstalling resolving dependencies... done. looking for inter-conflicts... done.
Targets: xf86-input-keyboard-1.2.2-2 xf86-input-mouse-1.2.3-1 xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-server-1.4-5 xorg-twm-1.0.1-2 xorg-xinit-1.0.7-1 xterm-229-2
Total Download Size: 22.89 MB Total Installed Size: 29.84 MB
Proceed with installation? [Y/n]
** Current behavior (anwering no to all uptodate questions) :
xav@nx7400> sudo pacman -S xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] :: xf86-input-keyboard-1.2.2-2: local version is up to date. Upgrade anyway? [Y/n] n warning: xf86-input-keyboard-1.2.2-2 is up to date -- skipping :: xf86-input-mouse-1.2.3-1: local version is up to date. Upgrade anyway? [Y/n] n warning: xf86-input-mouse-1.2.3-1 is up to date -- skipping :: xorg-server-1.4-5: local version is up to date. Upgrade anyway? [Y/n] n warning: xorg-server-1.4-5 is up to date -- skipping :: xorg-xinit-1.0.7-1: local version is up to date. Upgrade anyway? [Y/n] n warning: xorg-xinit-1.0.7-1 is up to date -- skipping :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] n warning: xterm-229-2 is up to date -- skipping resolving dependencies... done. looking for inter-conflicts... done.
Targets: xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-twm-1.0.1-2
Total Download Size: 22.89 MB
Proceed with installation? [Y/n] n
** New behavior with --needed:
xav@nx7400> sudo src/pacman/pacman -S --needed xorg :: group xorg: xf86-input-keyboard xf86-input-mouse xf86-video-vesa xorg-fonts-100dpi xorg-fonts-75dpi xorg-res-utils xorg-server xorg-twm xorg-xinit xterm :: Install whole content? [Y/n] warning: xf86-input-keyboard-1.2.2-2 is up to date -- skipping warning: xf86-input-mouse-1.2.3-1 is up to date -- skipping warning: xorg-server-1.4-5 is up to date -- skipping warning: xorg-xinit-1.0.7-1 is up to date -- skipping warning: xterm-229-2 is up to date -- skipping resolving dependencies... done. looking for inter-conflicts... done.
Targets: xf86-video-vesa-1.3.0-5 xorg-fonts-100dpi-1.0.1-1 xorg-fonts-75dpi-1.0.1-2 xorg-res-utils-1.0.3-2 xorg-twm-1.0.1-2
Total Download Size: 22.89 MB
Proceed with installation? [Y/n]
And this would ~close http://bugs.archlinux.org/task/8242, imho. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Fri, Nov 23, 2007 at 12:13:01PM +0100, Nagy Gabor wrote:
And this would ~close http://bugs.archlinux.org/task/8242, imho.
Actually, I agree with Aaron here : "This has nothing to do with questions.... solving this issue with noconfirm is messy. What we *should* do is literally keep track of whether something installed is a group or a package." I think the example in the bug report is quite clear : "pacman -S gnome-extra *few weeks later* gnome-extra adds 2-3 new packages pacman -Syu doesn't catch this and install the 2-3 new packages." You install a group one day. And after that, you just run pacman -Syu. Having to reinstall every groups to ensure that no new packages appeared in the meantime isn't very nice. Or at least, that's not what the feature request is about. But that also means every "pacman -S group" would have to be recorded. Now, where I might agree with you is about the usefulness of this feature request. I personally wouldn't care about this problem on my system. Even if I did, it would probably be for a specific group. So in that case, "pacman -S needed group" would help indeed. But then I wouldn't consider FS#8242 as fixed, rather as invalid :)
participants (4)
-
Dan McGee
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier