On 10/2/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 10/2/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 9/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2007/9/28, Xavier <shiningxc@gmail.com>:
Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here.
The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue?
The description of -Qu says : -u, --upgrades list all packages that can be upgraded
IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu.
Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n]
But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.
I also quote Aaron's comment from Flyspray:
I want one function that says "give me a list of packages that are upgradable". This function can be used in -Qu (simply returning the list and printing), -Su (using the list as targets), and -Sup (returning the list and calling some public alpm_pkg_get_url() on each member).
A public accessor to get a URL for a package can make -Qu and -Sup almost the same, except with different output functions.
I uderstand "a list of packages that are upgradeable" as a list of _already_installed_ packages that have newer versions available or there are new packages that replace them. This is different from the list that -Su and -Sup gives, because they list packages that are _going_to_be_installed_, including new dependencies. And this is also different from -Qu. The description of -Qu says "list all packages that can be upgraded" But -Qu doesn't do this! It displays _new_versions_(and replacements)_ of currently installed packages. This is different.
Yeah yeah - -Su would do one extra step in this case. It would take the list of packages and resolve the dependencies as well.
We could, of course, do that as part of the "upgradable" check - I could see it either way.
But, I guess, my point is this. The logic COULD be the same, and it would make much more sense to get a list of packages without the need for this clunky "transaction object", applying the transaction around the INSTALL only.
I agree with Aaron here about the transaction object stuff. We shouldn't need that just to get a list of upgrades.
I personally think -Su and -Qu (and their libalpm counterparts) should return the same list of packages to be installed, whether or not they are upgrades or pulled in deps. What is the disadvantage to this? -Qu was meant to be an alternative to canceling an -Su just because you wanted to see what needs upgrading.
Yeah, I don't see any reason why we couldn't resolve deps (which is the difference here, right?) while doing this, BUT I fear that makes more of a hassle. Adding functionality which allows us to get "upgradable" packages, AND functionality which allows us to resolve deps in a non-transactional, read-only manner would make all of our lives easier. Maybe I will have some time tonight to crack this out....