On Fri, Aug 22, 2008 at 12:03 PM, Xavier <shiningxc@gmail.com> wrote:
This issue has been known for ages, and it is easy to fix it, so I would like to do it. http://archlinux.org/pipermail/pacman-dev/2008-May/011885.html Example of a bogus output taken from the forums (the thread does not talk about this issue though) : http://bbs.archlinux.org/viewtopic.php?pid=343166#p343166
My attached solution simply removes the messages, which are in my opinion useless. But I asked if it was a problem here : http://archlinux.org/pipermail/pacman-dev/2008-June/012095.html If this is a problem, the rest of my patch will allow me to easily reintroduce these messages when they are relevant.
To be clearer, here are the 3 situations possible :
1) local version (release 1) is older than sync (2)
myhost% LANG=C sudo pacman -S bash resolving dependencies... looking for inter-conflicts...
Targets (1): bash-3.2.039-2
2) local and sync are the same : 2
myhost% LANG=C sudo pacman -S bash warning: bash-3.2.039-2 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts...
Targets (1): bash-3.2.039-2
3) local (3) is newer than sync (2)
myhost% LANG=C sudo pacman -S bash warning: bash: local (3.2.039-3) is newer than core (3.2.039-2) warning: bash-3.2.039-3 is up to date -- reinstalling resolving dependencies... looking for inter-conflicts...
Targets (1): bash-3.2.039-2
1) and 2) are already fine. Only 3) is wrong : here we don't want to display the "up to date" message. _______________________________________________
0. I don't like this _alpm_pkg_compare_versions() function at all, it has some annoying warning messages (why is the "forcing upgrade..." message important?), these reduce its usability (hardwired "upgrade" word etc.). This function is just a vercmp + force check + printing some (useless?) warnings. (The second "downgrade" warning also seems a bit odd in "-S target" operation because of mentioning the repo.) 1. After your patch we won't display warning in 2) case neither (as you wrote in patch description). I am not sure this is better. I would simply inform user about both downgrade (but not in pkg_compare_versions!) and reinstall instead. 2. The patch silently modifies (fixes?) --needed behavior (probably this is why you changed its description, but it wasn't clear to me first): Before your patch --needed prevented us from _downgrade_ too, now it will allow it. Bye