Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#7884 - Pacman -Qu list differs from pacman -Su list

Attached to Project: Pacman
Opened by Dan McGee (toofishes) - Friday, 24 August 2007, 01:20 GMT
Last edited by Dan McGee (toofishes) - Saturday, 01 November 2008, 00:44 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Xavier (shining)
Dan McGee (toofishes)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.0.5
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Problem that I noted with 3.0.X releases- pacman -Qu isn't always the same as pacman -Su, it seems to miss pulling in a lot of the dependencies. We should work that out before we close this bug report, or at least open a new one to address that issue.

Here is an example:

dmcgee@dublin ~
$ pacman -Qu
Checking for package upgrades...

Targets: cpio-2.9-1 docbook-xsl-1.73.0-1 ed-0.8-1 glib2-2.14.0-3
graphviz-2.14-2 gtk2-2.10.14-3 intltool-0.36.1-1 kdelibs-3.5.7-5
libarchive-2.2.6-1 man-pages-2.64-1 pciutils-2.2.6-1
readline-5.2-3 xterm-229-1

Total Package Size: 35.63 MB

$ sudo pacman -Su
:: Starting full system upgrade...
resolving dependencies... done.
looking for inter-conflicts... done.

Targets: cpio-2.9-1 docbook-xsl-1.73.0-1 ed-0.8-1 glib2-2.14.0-3
gd-2.0.35-1 graphviz-2.14-2 gtk2-2.10.14-3 intltool-0.36.1-1
kdelibs-3.5.7-5 libarchive-2.2.6-1 man-pages-2.64-1
pciutils-2.2.6-1 readline-5.2-3 xterm-229-1

Total Package Size: 35.80 MB
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 01 November 2008, 00:44 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Woo closing old bugs
Comment by Xavier (shining) - Friday, 24 August 2007, 10:55 GMT
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?
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 05:31 GMT
  • Field changed: Due in Version (Undecided → 3.1.0)
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.
Comment by Xavier (shining) - Friday, 28 September 2007, 13:38 GMT
It's on my git tree, upgrade branch :
gitweb :;a=shortlog;h=upgrade

The thread on the ML is there :
Dan offered some comments, so I updated the patch accordingly :

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.
Comment by Xavier (shining) - Friday, 28 September 2007, 15:48 GMT
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
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 15:53 GMT
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.

Comment by Xavier (shining) - Friday, 28 September 2007, 18:23 GMT
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.
Comment by Aaron Griffin (phrakture) - Friday, 28 September 2007, 18:36 GMT
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)
Comment by Dan McGee (toofishes) - Thursday, 29 November 2007, 20:04 GMT
Did this get addressed with your sysupgrade patch, Xavier?
Comment by Xavier (shining) - Thursday, 29 November 2007, 23:51 GMT
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.
Comment by Nagy Gabor (combo) - Friday, 29 February 2008, 18:35 GMT
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.
Comment by Gavin Bisesi (Daenyth) - Monday, 11 August 2008, 17:56 GMT
This bug is marked for 3.1.0
What's up with it?
Comment by Xavier (shining) - Monday, 11 August 2008, 18:14 GMT
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.