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#43012 - "pacman -Rp" (--remove --print) does not print targets if a HoldPkg was found

Attached to Project: Pacman
Opened by Score_Under (Score_Under) - Friday, 05 December 2014, 04:54 GMT
Task Type General Gripe
Category Output
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:

I'm not sure if this is a bug (if not, maybe the man page could mention this).
When attempting to print the list of targets for a --remove operation, if a HoldPkg is one of those targets, the list will never be printed. Instead ":: HoldPkg was found in target list. Do you want to continue? [y/N] " will be printed and pacman will exit immediately with error code 1.

Steps to Reproduce:

pacman -Rcp pacman
This task depends upon

Comment by Dave Reisner (falconindy) - Friday, 05 December 2014, 23:05 GMT
What would you suggest as an alternative? Note that the current implementation is *accurate*, as no packages will be removed without user intervention to decide the fate of the HoldPkg.
Comment by Score_Under (Score_Under) - Saturday, 06 December 2014, 04:17 GMT
Since the behaviour is accurate:
Interaction is impossible, so I think "Do you want to continue?" is a strange message to print. Since the command is likely to have its stdout captured and treated as a package list, it would probably make more sense if the message appeared on stderr.
Comment by Dave Reisner (falconindy) - Saturday, 06 December 2014, 16:13 GMT
Ah, didn't catch that part. Seems to be due to this:

https://projects.archlinux.org/pacman.git/tree/src/pacman/util.c#n1384

Which dates back to 2008... The same behavior exists in multiselect_question. Offhand, I'm not sure why we couldn't *always* dump this to stderr.

Loading...