Arch Linux

Well, Qu doesn't do any dependencies resolving, it just checks for new package.
And well, it does what the doc says :
-u, --upgrades list all packages that can be upgraded

For example, the new graphviz version above (2.14-2) just pulled in a new dependency : gd.
gd isn't a package that can be upgraded, it's just a dep of a package (graphviz) that can be upgraded.

I think that not displaying gd in -Qu can be seen as a feature rather than a bug.

But anyway, I really don't like that -Qu option. Firstly because the code is duplicated, and secondly
because I'm not sure which use it has.

Besides, there is apparently a similar -Sup option for printing uris.
What about having for example -Sup for printing package name and version, and -SuP for printing uris, or something like that?

Monsieur shining,
Could you point me to (or send to the ML) the patches you had for this. Dan mentioned you had a chunk to unify the -Qu and -Su stuff, which would be great, and I wanted to reuse the same logic to redo the way PRINTURIS works.

It's on my git tree, upgrade branch : http://chantry.homelinux.org/~xav/git/pacman.git/
gitweb : http://chantry.homelinux.org/~xav/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=upgrade

The thread on the ML is there :
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009188.html
Dan offered some comments, so I updated the patch accordingly :
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009223.html

But, what about my comment above?
It's questioning the fact that this bug is really a bug, and not rather a feature.

But, if we really want -Qu and -Su to be the same, I was thinking about tweaking the PRINTURIS flag.
For example, renaming it to PRINT only or something, and then somehow allow choosing between uris and package name.

Hm, a lot happened on IRC tonight. Just finished reading that stuff.
Actually, what my patch does is not really what you want. I even wonder if it doesn't go a bit in the opposite direction.
It is just the simple solution I saw for killing the duplicated alpm_get_upgrades function.

Also, it has not much to do with this bug report. -Qu still behave the same way as before.
It doesn't do all the dependencies resolving stuff done by -Su.

This PRINTURIS flag allows to keep all the jobs done by -Su, and is used only by -Sup currently. I thought it could be used by -Qu as well.
But if both pacman developers think that this whole PRINTURIS flag thing is hackish, I am not sure what to propose :)

It seems that, instead of reimplementing -Qu like -Sup, you want to do the opposite, reimplement -Sup based on -Qu.
That might be cleaner, but then we will have the same problem with -Sup than we currently have -Qu : it won't include the dependencies.

Imo, it's not a big deal if dependencies aren't displayed by -Qu, this behavior also match the documentation : -u, --upgrades list all packages that can be upgraded
On the other hand, its important that -Sup does it, otherwise this option is useless : -p, --print-uris print out URIs for given packages and their dependencies

Well see, here's what I'm looking for.

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.

Alright, just pointing out that having only the strict list of packages that are upgradeable (returned by alpm_db_get_upgrades(void)) would be worse for -Sup than it is for -Qu.
That is, in Dan's example above, it's more important to have -Sup display the url of gd, than having -Qu display the gd package.

Also, in my opinion, the non-interactivity is more important for -Qu than for -Sup.

But... ok. In pseudo-python-ish-code:

pkgs = alpm_db_get_upgrades()

if "-Qu": for pkg in pkgs: print pkg
elif "-Sup": for pkg in pkgs: print alpm_pkg_get_url(pkg)

Did this get addressed with your sysupgrade patch, Xavier?

Unfortunately not, as I said above, my patch only eliminated duplicated code. But the -Qu behavior remains exactly the same.
It does only the first step of a sysupgrade (looking for newer packages).
It doesn't do the whole dependencies resolving / conflicts handling from sync_prepare.

Today I looked into the code around this -Qu. We could continue the implementing (in 1.-way), but I'm against this FR and I suggest revert the current implementation too, because:
1. the code became very ugly, we have four(!) sysupgrade functions in alpm: alpm_trans_sysupgrade, _alpm_trans_sysupgrade, alpm_sync_sysupgrade, and _alpm_sync_sysupgrade (the real part).
2. the front-end cannot free the package list he got from alpm_sync_sysupgrade (usually this is done by trans_release, but this is not a transaction)
3. As it was mentioned several times, -Sp can simulate perfectly the transaction (user can answer to the replaces questions etc.), and simulating a transaction (including conflicts, dependencies etc.) without a transaction in -Q is a nightmare.
4. IMHO -Qu for listing outdated packages is better (with the help of alpm_sync_newversion this is ~5 lines), we can apply filter() to resultant list on request. (Currently we just use the usual list_diplay as a summary with to-be-removed packages, too...). And imho -Q refers to local packages not to sync packages.

This bug is marked for 3.1.0
What's up with it?

I will just follow last Nagy's comment here.
This is not a bug, the -Qu operation just does not do the dependency resolving, thus the output is different than -Su, but it is not a problem.
And I agree that the current -Qu implementation is rather ugly so I am for reimplementing it the way Nagy said.
But this has nothing to do with this bug, so I would just close it.
This bug was opened by Dan though, so I will wait for his decision.