Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#3351 - pacman -Q {list} behaviour

Attached to Project: Pacman
Opened by Damir Perisa (damir.perisa) - Monday, 17 October 2005, 14:14 GMT
Last edited by Roman Kyrylych (Romashka) - Monday, 13 November 2006, 22:51 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Low
Priority Low
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

wanting to know what versions of packages i have on my system for bug
http://bugs.archlinux.org/index.php?do=details&id=3346
i did this:

[damir@Asteraceae ~]$ pacman -Q octave gcc gcc-fortran gcc-g77
octave 2.1.71-4
gcc 4.0.2-2
gcc-fortran 4.0.2-2
Package "gcc-g77" was not found.

[damir@Asteraceae ~]$ pacman -Q octave gcc-g77 gcc gcc-fortran
octave 2.1.71-4
Package "gcc-g77" was not found.

[damir@Asteraceae ~]$

and discovered, that the order in this list does depend, because if a package is not found, it stops and ignores the rest of the list.

should-be behaviour: check all items of the list, no matter what result it gets.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Wednesday, 22 November 2006, 07:10 GMT
Reason for closing:  Implemented
Additional comments about closing:  -Q operations now carry on with an error message when a missing package is found. Other "parallel" operations should be dealt with on a case-by-case basis as they come up
Comment by Roman Kyrylych (Romashka) - Monday, 13 November 2006, 22:50 GMT
The same is true for other pacman options which take multiple arguments.
Comment by Aaron Griffin (phrakture) - Monday, 13 November 2006, 23:04 GMT
Hmmm, not sure if I'd count this as a bug. I mean, if you type out, say, 100 packages, and one in the middle is wrong, you may never know it wasn't properly installed. I actually think this is worthwhile for the most part, though it might be safe to continue on with non-root operations (-Q)
Comment by Damir Perisa (damir.perisa) - Monday, 13 November 2006, 23:31 GMT
maybe it's better to differenciate between

- serial processes (like updating a pkg with dependencies)
- parallel processes (like updating independend pkgs or querying db)

on the serial, i agree, it should exit with 1 and stop going further
on parallel, one expects it to do things independendly and in the end just tell it had some problems with some points

one of the problems now is that pacman is not aware (as far i guess) on the dependencies when doing -S or -U ... so it takes everything as serial and stops upon any problem. this may be not very trivial to change.

the "non-root" actions (easily classified as parallel) should be able to be run in parallel respectively independendly from each other's outcome

Loading...