[pacman-dev] -Qu vs -Su

[Aaron Griffin]

On 10/2/07, Dan McGee <dpmcgee at gmail.com> wrote:
> On 10/2/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > On 9/29/07, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > > 2007/9/28, Xavier <shiningxc at 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....