Feature requests should be specific, realistic, and actionable. Make sure you say what benefit the feature would have.
I agree. Having pamac that logs its own output provides the user with actionable information not found in pacman’s default log found in
In the event of x session crash, the user will know potentially at which stage (and at which package) in the update process the crash occurred. As I’ve found out, a “ghost package” may be created but finding a corrupted package (in general) through conventional means (-Qkk, this, or this) can prove to be a difficult process. Pacman.log will log successful package installs, but fails to notify at which package when the update process terminates – and the issue is further complicated because the list is not necessarily in alphabetical order.
A smart log can perhaps be created to immediately notify the user that a package’s post hooks (/usr/share/libalpm/hooks/) need to be run in order for the update process to fully complete – if the process was interrupted early. More reading material about this problem here. The point of this notification system is to catch the user to fix the problem before they reboot and potentially bork their system.
There may be other edge-cases where having additional logged information may be beneficial to have, for example during a power outage or a hardware failure interruption during the update process. Updating from a partially-synced mirror may result in a partially-updated system – but, logged timestamped package offerings may assist the user. A fully-logged process takes the guesswork out of diagnosing and resolving issues later.