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#24287 - pacman -Sc --print behaves like --noconfirm

Attached to Project: Pacman
Opened by Dario Giovannetti (kynikos) - Sunday, 15 May 2011, 14:50 GMT
Last edited by Dan McGee (toofishes) - Thursday, 19 May 2011, 22:22 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Dan McGee (toofishes)
Architecture x86_64
Severity High
Priority Normal
Reported Version 3.5.2
Due in Version 3.5.3
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

"pacman -Sc --print" behaves like "pacman -Sc --noconfirm": I would expect it either to write a list of the files to be deleted, or ignore "--print", or do nothing at all, or return an error, but for sure not clean the cache without asking for confirmation, like using "--noconfirm".

Tested only on x86_64.

Steps to reproduce:
# pacman -Sc --print
or:
# pacman -Scp
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 19 May 2011, 22:22 GMT
Reason for closing:  Fixed
Additional comments about closing:  Commit ba467779bb0fa
Comment by Dan McGee (toofishes) - Sunday, 15 May 2011, 15:59 GMT
This is due to our "set up the print operations" stuff (search for that comment, current line ~887) in pacman.c being a bit too overzealous.
Comment by Dario Giovannetti (kynikos) - Sunday, 15 May 2011, 16:32 GMT
I see, I set severity high because I didn't know if this behaviour could somehow involve other more critical operations.
Comment by Dan McGee (toofishes) - Sunday, 15 May 2011, 16:35 GMT
Yeah, that was mainly a note to myself since I dug into it a bit. There is definite possibility for this affecting other operations, but due to the way we handle sync cleaning very early the damage is probably fairly limited. I do agree that we should act smarter in this situation; it probably comes down more to implementing  FS#20950 .

Loading...