FS#12419 - pacman should output info about .pacnew files at the end
Attached to Project:
Pacman
Opened by bughunter2 (bughunter2) - Thursday, 11 December 2008, 23:16 GMT
Last edited by Dan McGee (toofishes) - Monday, 22 December 2008, 18:24 GMT
Opened by bughunter2 (bughunter2) - Thursday, 11 December 2008, 23:16 GMT
Last edited by Dan McGee (toofishes) - Monday, 22 December 2008, 18:24 GMT
|
Details
Pacman should output messages about .pacnew files after it
is done with
updating packages, not meanwhile every package is being updated. The messages should be collected and displayed at the end, when pacman is done with everything. I've discussed this on the #archlinux IRC channel, and I was being told this feature would be called bloat. It's not bloat, it's just *moving* a few of pacman's outputted messages to another place, namely at the end after it's done updating. You could call it a "summary" about the .pacnew files. This would be nice to have, since then you don't have to use "yes | pacman -Syu | less" or "pacman -Syu && updatedb && slocate *.pacnew". I'm not saying I need this feature, but I find it helpful and I'm sure a lot of users (especially newcomers) will love this feature. One might argue that it's not the responsibility of the tool and that it does not conform to the UNIX philosophy "do one thing and do it well". This isn't true since in this case, pacman is doing one thing not well, namely being user friendly. Simply *moving* the messages from the output of pacman to the end of its output makes it more *friendly* to see what the user needs to do. It's not bloat, it's just moving some output of a feature that was already there. If you say it is bloat, then you might as well remove the feature of telling the user about .pacnew files at all, since that is the real feature. I'm just giving a suggesting about how to make the existing feature more *useful*. Also you can say the user should read everything pacman says anyway, but there are priorities to what the user should read. For example: --> It is recommended to use qjackctl as a controlling frontend for the --> audio server. The extended rights for realtime capabilities can be --> granted based on groups or a per user base in --> /etc/security/limits.conf Thinks like that are relatively unimportant since one might not want to use qjackctl at all. Thus, updating .pacnew files should be seen as a higher priority, since important system files might have to be updated. So, it might be helpful to move the high priority items to the end of pacman's output. Though, this feature request is merely limited to .pacnew files. You could say a user should always know what to do, because the user is the system administrator. But just moving a message is helpful in this case, it's not trying to make the user more dumb, it's just a reminder. (And if you do say that the user is responsible for doing everything on their own and the system should manage nothing on its own, you might as well remove the automated process of updating the kernel image with mkinitcpio after a kernel upgrade. Since, after all, the user should do it.) |
This task depends upon
Closed by Dan McGee (toofishes)
Monday, 22 December 2008, 18:24 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments. The easiest approach to get similar behavior is to grep pacman.log when pacman terminates for any pac* messages.
Monday, 22 December 2008, 18:24 GMT
Reason for closing: Won't implement
Additional comments about closing: See comments. The easiest approach to get similar behavior is to grep pacman.log when pacman terminates for any pac* messages.
Lazy people have nothing to do with this, since the software is just helpful by notifying you something (and in a manner that is more user friendly than it currently would be).
Technical problems or bad design are a lazy excuse to not make software user friendly.
User friendliness != Lazyiness
Technically, grouping them would be harder, but that didn't really factor into my decision. Other things worth considering, however- what happens if pacman barfs and you queue messages? Not that it happens often (if ever) anymore, but its something worth considering anytime message queueing comes up.
We have quite a few configuration parameters already, and this would be yet another. I'm just not in support of it. We trust that our users actually read program output because we try hard not to spit out unnecessary information, and if they can't be bothered to do that I'm not convinced moving it to the end will suddenly fix the situation.
http://wiki.archlinux.org/index.php/Pacnew_and_Pacsave_Files
If the pacman devs could review it and make (or suggest) necessary corrections I'd be grateful.